A restic client written in rust

Community
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
Restic snapshot confusion
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
Data integrity testing
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
85

Storage backends… this one is tricky and I am not sure myself what is the best way to compare it.

Let’s say S3 - both restic and rustic support it out of the box. “via opendal” for rustic suggests that some extra software is needed which is not true. It is just technical implementation detail. restic I bet is using some 3rd party library here as well.

rustic supports much more backends without need to install and configure additional software. But both support rclone for whatever this handy utility supports.

From end user perspective this is what I am interested about - what I can use for repo without anything extra. And with rustic for example I can use onedrive when with restic I would have to install and configure rclone

1 Like