Comparison with Restic

[nickchomey]

I just discovered this now. I'm wondering if you could create some sort of feature comparison table to show how this compares to restic (and maybe even other popular tools) so that we can easily evaluate if this will suit our needs.

Moreover, perhaps it would be worth adding some detail to the readme explaining why this exists as opposed to just continuing to contribute to restic or others tools?

[aawsome]

@nickchomey Thanks a lot for your issue! For the first part, I would be also very interested to have this. Currently, there is

• the (surely incomplete) comparison short-list on the README
• the FAQ which explains some things
• the help pages that can be accessed by rustic-rs help or rustic-rs <command> help and hopefully give an good idea what the command and the various options are doing.

If you or anyone else finds improvements to any of these, please contribute and propose a PR!

[aawsome]

About the second question, I think in open source there is a good answer to this type of question: Because we can and we want!

I can give you some of my personal motivations:

• I liked to learn Rust and knowing the details of restic I thought the best way to get an inside of a new language (and "feel" the pros and cons) is to re-implement something you've already implemented. Or the other way round: You only know a programming language if you solved real problems with it.
• Rust is said to be very resource-efficient (if you do it right). As should be a backup tool. So I think it is a good fit. And current results show that rustic is MUCH more resource-efficient than restic.
• I like restic very much, but it misses some features I'd really like to have (like cold storage support)
• To be fair, it is much easier to develop crazy new features on a re-implementation if you still have an reference at hand for checks and as a "backup tool" which can also access your data. This is also the reason why rustic so far only makes non-breaking additions to the formats used with restic.
• The development of restic seems REALLY slow to me. This is not meant as discredit for restic or its maintainers, but it is the result of very few people maintaining restic. And while it is a very fair decision to keep numbers of maintainers low, I would try to increase it to move faster.
• Also, as very personal motivation, I made many PRs for restic. Many of them have been merged, but also many are still open for more than a year. For me it doesn't make much sense to add more work before these are mostly "completed", so I'm kind of stuck.

So I find myself working for rustic and happily improving it and adding new cool features. I am very proud that in many aspects it already equals restic or even outperforms it. The only drop of bitterness so far is that one of my critic about restic (having so few maintainers) so far also holds for rustic. Actually, I am hoping for more people to contribute and I promise to sooner than later manage how this project will scale with more people working for it. (I'm thinking about something like the C4 Collective Code Construction Contract process to get Contributors involved)

[nickchomey]

Thanks very much! That all makes sense and I look forward to seeing your progress (I won't be able to contribute anything).

I really do think, however, that a table that lists/compares as many features as possible with restic would be very useful. Most people are probably not familiar enough with what restic offers to really get much value out of the comparison in the readme. A table with yes/no or some other indicator would make it very clear, very quickly.

[aawsome]

Actually there are many ways to contribute. Also people who test and report bugs or issue feature requests are highly welcome :smile:

[nickchomey]

I'll be happy to keep suggesting features and testing them out!