I’ll open a new one shortly, give me a sec, i have some rustic questiion to post here
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 ?
@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…
it was the no-cache
left enabled when i’ve copied an example config.
Now a new backup needs less than 1 minutes
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)?
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.
That is exactly what I was looking for.
Do you have any experiences with rustic? Is it trustworthy?
How about implementing merge for restic?
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
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.
Rustic’s web site loudly proclaims it is beta, and lacks tests.
Has it eaten any days recently or ever?
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.
webdav thing is so cool - I am tired of fuse problems on macOS:)
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 likerestic 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!
Sorry, this was in fact really a typo - especially given that rustic doesn’t yet support --read-data-subset
.
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!
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
Thanks for your feedback! I updated the backend section to be more precise about what is built-in and what needs extra external tools.