A restic client written in rust

Community
65

thank you. i’ll do in this way

1 Like
66

I have one more thought about your issue. Your solution unfortunately is not really practical and your repo can be attacked anyway.

Thx to rustic no lock files operations you can create WORM (write once read many times) repository using your locked GCS bucket. But it also means you will never be able do delete anything (forget won’t work). Does it make your repo safe? Nope. As after 60 days in your example attacker can delete older files - effectively crippling all repo. You could only avoid it if your lock has no expiry. It means that your repo will grow forever… or is only safe for 60 days… It is not good IMO.

I think this thread is not the best place to discuss it further. I suggest you open new thread. I have some ideas how to implement it using any backup program.

1 Like
67

I’ll open a new one shortly, give me a sec, i have some rustic questiion to post here

1 Like
68

Testing a full backup with rustic.
Called 2 times rustic backup and this lead to a full backup, but every time the backup is done fully, not only changed files, as you can see from the snapshot lists. (and it takes 20 minutes every time):

# rustic snapshots
using config /root/.config/rustic/rustic.toml
[INFO] repository rclone:gcs:x/my-srv: password is correct.
[INFO] using no cache

snapshots for (host [my-srv], label [], paths [/])
| ID       | Time                | Host   | Label | Tags | Paths |  Files |  Dirs |    Size |
|----------|---------------------|--------|-------|------|-------|--------|-------|---------|
| 459f9320 | 2024-01-05 13:24:41 | my-srv |       |      | /     |      2 | 37463 |     0 B |
| 4a956b81 | 2024-01-05 13:47:28 | my-srv |       |      | /     | 225832 | 29693 | 8.4 GiB |
| fdaf236f | 2024-01-05 14:14:29 | my-srv |       |      | /     | 225835 | 29693 | 8.4 GiB |
3 snapshot(s)

total: 3 snapshot(s)

this is the config:

[repository]
repository = "rclone:gcs:x/my-srv"
password-file = "/root/.config/rustic/password"
no-cache = true # no cache needed for local repository

[forget]
keep-hourly = 24
keep-daily = 180
keep-monthly = 6
keep-yearly = 1

[backup]
iglob-file = ["/.rusticignore"]
host = "my-srv"

[[backup.sources]]
source = "/"

what i’m doing wrong ?

1 Like
69

@guestisp First, please use a cache with a remote backend (remove the no-cache = true line). It could be that your backup is just slow bacause you don’t use a cache.

Can you give the output of rustic snapshots --long? This should show us what rustic really did here…

1 Like
70

it was the no-cache left enabled when i’ve copied an example config.
Now a new backup needs less than 1 minutes :slight_smile:

3 Likes
71

I know that this is rEstic, but rUstic uses the same repo format.

Where would I go for support for rUstic?

Is there a forum (surely it’s not all supported via GitHub issues)?

72

Moved your question to the rustic thread. There’s the rustic discussions on GitHub, I think that’s the place where discussions about rustic happens.

1 Like
73

Cheers!

For others looking: rustic-rs/rustic · Discussions · GitHub

1 Like
74

That is exactly what I was looking for.

Do you have any experiences with rustic? Is it trustworthy?

How about implementing merge for restic?

75

It’s as trusthworthy as you make it.

It’s a matter of what features and maintenance to prioritize. You can see the current roadmap for restic here: Roadmap for restic 0.17 to 0.19

1 Like
76

I’ve been using it for some time and it works perfectly for me.

You can always use both (actually this is what I do) e.g. in your case only use rustic only to merge snapshots.

1 Like
77

Rustic’s web site loudly proclaims it is beta, and lacks tests.

Has it eaten any days recently or ever?

78

No - never got a bug report of this kind. In general bugs which might lead to repository inconsistencies or even data loss are always rated highes priority and would be fixed very soon.
But so far almost all bugs were about rustic not doing things as expected, but not about critical stuff with respect to repository or data integrity.

1 Like
79
80

webdav thing is so cool - I am tired of fuse problems on macOS:)

1 Like
81

rustic 0.7.0 has just been released.

Besides the already announced milestones - many remote storages natively supported and the new webdav command - there are several other enhancements, e.g.:

  • New options for backup: --custom-ignorefile, --skip-identical-backup, --no-scan, --quiet.
  • Allow better and more configuration of repository storage via the config file.
  • Even more memory reduction in case of large repositories.
  • New option prune --early-delete-index (which is like restic prune --unsafe-recover-no-free-space)
  • New option ls --numeric-id (in combination with --long)
  • Many minor bugs have been fixed.

For more details, have a look at the release notes

Thanks a lot to all people who contributed code, bug reports or discussions!

2 Likes
82

Is this a subtle advertisement? :wink:

1 Like
83

Sorry, this was in fact really a typo - especially given that rustic doesn’t yet support --read-data-subset.

1 Like
84

FYI, we have collected an in-depth feature comparison between restic and rustic (general features and detailed feature-compare for important commands):

Feedback very welcome!

3 Likes