How long would it take for one person to write the whole Restic or Rustic?
Just wondering what you want to learn by an answer of this question… Can you rephrase what your interest is?
The point is, it depends a lot on
- the skill of the person
- the knowledge of the person about repository internals and process internals
- the time the person can spend per day/week/month working on the implementation
As reference, I’ve been working on rustic roughly 1 1/2 years in my spare time but having worked a lot on all kind of restic internals before.
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…
1 Like
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 --initallows to initialize a repository with the first backup. - Option
--jsonis now available for more commands. - New options
ls --longandls --summary. - Configuration files are now also searched in system-wide config dirs.
- rustic now allows to set env variables in the configuration files.
- many minor bugs have been fixed.
- …and more, see the changlog!
3 Likes
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.
1 Like
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…
4 Likes
Trying rustic… is Google Cloud Storage supported like in restic or not ? Because trying to use gc backend trigger an error…
1 Like
Only local, rclone and REST backends are supported - Preparing a new repository - rustic user documentation
Use rclone to connect to GCS.
2 Likes
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.
1 Like
And which is the best way to store the repository password while keeping it secure from compromissions ?
1 Like
You can always copy snapshots to another repository. Check rustic copy.
You can not move anything as your source repository is effectively read only.
Use your OS provided keychain.
For example this is what I do on macOS:
- 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.
1 Like
yeah, copy was the wrong term. i mean’t backup to a second provider.
1 Like
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.
1 Like
thank you. i’ll do in this way
1 Like
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
I’ll open a new one shortly, give me a sec, i have some rustic questiion to post here
1 Like