I also thought about the name and decided to let it as it is. The official name is actually “rustic-rs” which is also the crate name. I think that in the future the code will be separated in a library crate which provides all the functionality and a binary crate providing one ore more small binaries.
At the moment I’m trying to convert the logic to async Rust. That will be the next step in order to use async http client libraries and will allow to implement more backends.
About new features: Let me take to opportunity to advertise some of the existing new features. The backup command is already fully working:
alex@debian:~$ ./rustic-rs backup --help
backup to the repository
rustic-rs --repository <REPOSITORY> backup [OPTIONS] <SOURCE>
<SOURCE> backup source
--exclude-if-present <FILE> Exclude contents of directories containing filename (can be
specified multiple times)
-f, --force Use no parent, read all files
-g, --glob <GLOB> Glob pattern to include/exclue (can be specified multiple
--git-ignore Ignore files based on .gitignore files
--glob-file <FILE> Read glob patterns to exclude/include from a file (can be
specified multiple times)
-h, --help Print help information
--iglob <GLOB> Same as --glob pattern but ignores the casing of filenames
--iglob-file <FILE> Same as --glob-file ignores the casing of filenames in
-n, --dry-run Do not upload or write any data, just show what would be done
--parent <SNAPSHOT> Snapshot to use as parent
--with-atime Save access time for files and directories
-x, --one-file-system Exclude other file systems, don't cross filesystem boundaries
Note the *glob* options which allow include/exclude patterns and the --git-ignore option.
Also as a small improvement the number of nodes and total (restore) size of a snapshot is saved in the snapshots:
The first snapshot was made by restic, the second by rustic (using the first as parent).
Of course it is much more easy to build a second implementation and early add some features there when there is always the reference implementation at hand.
But I hope we can use this second implementation to get benefits in both directions.
I did some comparisons with my repositories with the result that rustic generally uses less resources (memory, CPU time) than restic. Note that, however, rustic is not yet fully parallelized, so some operations which highly benefit from parallelization perform faster on restic if you have some CPU cores at hand.
Feel free to do your own tests or a qualified comparison and report at the rustic discussions or issues.
Note that rustic compiles to a single binary with no or only standard dynamic library dependencies. You can either use a pre-compiled version (see the rustic github page) or compile it yourself by doing:
How many lines of code are rustic and restic? And how long did they take you guys to write that code?
Restic is very popular and has many developers on GitHub, around 300. I don’t know to what extent they are involved, but the numbers are large. For rustic I imagine this is far fewer, seems to be 7 people, so you have to mostly write the code?