A restic client written in rust

Community
43

The docu is still WIP. But you can work very well with the CLI help: rustic --help or rustic <COMMAND> --help should give you good information. Also feel free to open a discussion if you have any questions!

44

Just curious: Would you describe rustic as a drop in replacement? So if I want to try it in my working setup of restic cronjobs, env variables and scripts, does it fit in without a lot of changes?

45

I first did describe it as drop-in replacement, but with the meaning that you can anytime switch from restic to rustic and vice versa as the repositories are 100% compatible.

This, however, led a bit to confusion as the rustic CLI does not work exactly as the restic CLI. Some commands or options differ a bit (besides the fact that the functionalities do not match 100%). The restic env variables do not work, but for most there are rustic env variables (if you change RESTIC into RUSTIC).

As rustic also supports a config file (see rustic/full.toml at main · rustic-rs/rustic · GitHub for reference), my recommendation is:

  • create a rustic config file - this should contain the contents of all your restic env variables
  • make a copy of your scripts changing restic to rustic

This should lead to ~95% working scripts, but you may need some finetuning afterwards.

Then, you can use your restic and rustic scipts concurrently. But note that for many use cases the configuration in the rustic config files are sufficient to describe what you want - I myself don’t use any scripts anymore since I switched to rustic.

1 Like
46

How long would it take for one person to write the whole Restic or Rustic?

47

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.

48

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.

49

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
52

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).

53

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.

54

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.
  • many minor bugs have been fixed.
  • …and more, see the changlog!
3 Likes
55

I am watching rustic from outside (and getting impressed :star_struck:). 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
56

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
57

Trying rustic… is Google Cloud Storage supported like in restic or not ? Because trying to use gc backend trigger an error…

1 Like
58

Only local, rclone and REST backends are supported - Preparing a new repository - rustic user documentation

Use rclone to connect to GCS.

2 Likes
59

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
60

And which is the best way to store the repository password while keeping it secure from compromissions ?

1 Like
61

You can always copy snapshots to another repository. Check rustic copy.

You can not move anything as your source repository is effectively read only.

62

Use your OS provided keychain.

For example this is what I do on macOS:

  1. Store password in keychain:
    security add-generic-password -a "restic_password_repoID" -s "restic_password_repoID" -w "my_secret_password"
  2. 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
63

yeah, copy was the wrong term. i mean’t backup to a second provider.

1 Like
64

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