The reason I asked You is, I see Rustic has fewer developers than restic. So, it must be that you developed a lot of the code individually.
The reason I asked the question is, I counted the number of lines of code to see the attack/bug surface, and it seems to be a lot of work. I thought that guy Alex must be faster than me if it was written in 1-2 years. Especially given that, writing in Rust is slower than other languages like python. Just to have an idea how far my skills are from benchmarks (assuming knowledge of repository), in the context of Restic software.
This is true - I would say about 90% has been developed by me. But developers base is increasing; currently we are two maintainers working on rustic. So I would say the project is in the process of changing from a 1-person-project to a multiple-maintainer-project.
This is maybe a huge discussion (which is totally off-topic here). I can confirm that learning Rust takes a bit of time. On the other hand, my personal experience is that I am much more productive with Rust compared to most other languages (including Python for my personal perspective) - I simply can spend a much higher amount of my time in coding instead of in finding bugs…
Is rustic a standalone cli backup tool (e.g borg) or something on top of restic (e.g creativeprojects/resticprofile)? (Note: I have not gone through every comment here and just had a quick loop at the github page).
rustic is completely written in Rust and does not depend on any part of the restic code - also not on the binary. The functionality it shares with restic is completely reimplemented.
I am very happy to announce rustic 0.6.0 and 0.6.1!
(0.6.1 is just a small bugfix release which fixed problems with build and the CI).
These are the first releases which use rustic_core for basically all functionality. Besides this, some new features have been added (most to rustic_core):
The restore algorithm is now much faster (and reportedly faster than restic restore) and works also more incremental making resumed restores faster.
New option backup --init allows to initialize a repository with the first backup.
Option --json is now available for more commands.
New options ls --long and ls --summary.
Configuration files are now also searched in system-wide config dirs.
rustic now allows to set env variables in the configuration files.
I am watching rustic from outside (and getting impressed ). Tbh only thing preventing me to try is direct s3 backend support. Don’t want to fiddle with another middle layer like rclone.
The next bigger refactoring will be to allow arbitrary backend trait implementations. The main reason for this is that it will allow to add much more integration tests using backend mocks.
But it will also allow to extract backed implementations into a separate Rust crate where we will add direct backend support for many services like S3…
Ok. i’m testing rustic+rclone. I’m able to backups and manage a GCS repository that is set with a bucklet lock (in example 60 days).
From the google console i’m unable to delete or alter existing files (as expected with a bucket lock) without removing the lock first.
Then i’ve tried to “forget” an existing snapshot and i was unable to remove it, as expected:
# ./rustic --password prova -r rclone:gcs:backup-test-restic forget 64047178
using no config file, none of these exist: /root/.config/rustic/rustic.toml, /etc/rustic/rustic.toml, ./rustic.toml
[INFO] repository rclone:gcs:backup-test-restic: password is correct.
[INFO] using cache at /root/.cache/rustic/d0d10299316166b204ee84f596262ba0e6cf998c1b40fdab3aa0bcaf0a176279
| ID | Time | Host | Label | Tags | Paths | Action | Reason |
|----------|---------------------|---------------------------------------------------|-------|------|-------|--------|-------------|
| 64047178 | 2024-01-05 10:30:56 | x | | | /root | remove | id argument |
[00:00:00] removing snapshots... ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0/1 [INFO] rclone output: 2024/01/05 10:33:33 ERROR : snapshots/6404717807a1d22cab3082eb60149d417fd1a7f610dc5af6708fdb56c0dd2a51: Delete request remove error: googleapi: Error 403: Object 'backup-test-restic/snapshots/6404717807a1d22cab3082eb60149d417fd1a7f610dc5af6708fdb56c0dd2a51' is subject to bucket's retention policy or object retention and cannot be deleted or overwritten until 2024-03-05T01:32:28.027919-08:00, retentionPolicyNotMet
With this configuration I think i’m protected from ransomware or host compromization, as existing backup can’t be removed/changed in any way, without removing the lock first (and the host can’t remove the lock)
Any other test shoul I do or something else to implement to increase the security ?
Another question: with restic/rustic is possible to have an additional level for backups ? In example, storing daily backups on GCS and moving the older one to AWS, using 2 storage providers for additional security.
Store password in keychain: security add-generic-password -a "restic_password_repoID" -s "restic_password_repoID" -w "my_secret_password"
I can retrieve it using: security find-generic-password -a "restic_password_repoID" -s "restic_password_repoID" -g
and then use in my backup script - --password-command
Keychain is only unlocked when I login to my user account.
All modern OS have similar functionality - keyring on Linux or credential manager on Windows. IMO it is much safer than home brewed solutions. At the end if you do not trust your OS than no method - however sophisticated - will protect you from rouge actors.
I would not copy anything as if source have corruption you copy it as well.
Run separate backup - ideally use different program:) This is what I do. Simply do not put all eggs in one basket. I run one restic/rustic backup to cloud1 and another using kopia to cloud2.
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.
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):