Interested in rustic?

[aawsome]

Hi @beeb

I just came over to your project when looking for other backup tools written in Rust. I myself created https://github.com/rustic-rs/rustic which is able to make encrypted, deduplicated backups to cloud storages, which IMO should include your use-case. I've seen that with respect to code your project is in an early stage, but you seem to have put quite some work into CI pipelines and deployment and you seem to put an focus on the automation of backups which is currently not in the scope of rustic.

Now I'm just wondering if we could benefit from each other. There could be several possibilities:

• you could use rustic in you project and basically wrap around its backup engine
• I'm also looking for other maintainers of rustic and would like to invite you to join or contribute if you're interested. Topics could be adding an s3 backend (currently only available via rclone), CI pipelines, tests or any feature you are missing for you use-case.

[beeb]

Hi @aawsome and thanks for reaching out!

I am not very familiar with restic and your compatible project but it looks very interesting. The feature set looks really nice and I would love to be able to use it at some point to power the core of awsbck.

Notably, I would be interested to one day support incremental backups, encryption and restoration.

I see that at the moment, everything is in a binary crate. Is there a plan going forward to split up core functionality as one or more separate library crates?

Regarding augmenting rustic to support the use case for awsbck via automation and S3 capabilities, I think it would maybe defeat the goal I set for myself to have an easy to configure system that can simply be setup with CLI arguments or environment variables and run inside docker without too much tinkering.

Thus I think the first suggestion adheres to my vision more closely and is something I could see myself working towards. I want to add cron expression support to awsbck before considering any future move, but after that I'd be happy to take a closer look at how I could contribute to rustic to enable some integration in my project.

Cheers!

[aawsome]

Notably, I would be interested to one day support incremental backups, encryption and restoration.

Just wanted to mention that deduplicated backups are much more powerful than incremental backups. You basically have only full backups (or snapshots) which you can deal with, but only need the (or even less) space and backup time which incremental backups would have needed.

I see that at the moment, everything is in a binary crate. Is there a plan going forward to split up core functionality as one or more separate library crates?

Yes, this is the plan and I actually already made quite some traits which would support this. The idea would be to have

• backend traits which should be implemented by the storage backend(s)
• source and target traits which should be implemented by the backup source or restore target (ATM: only local FS supported)
• library functionality to backup from source to the backend, to restore from backend to target and to do all the other things.

I realized that there is no issue so far, so I created one: https://github.com/rustic-rs/rustic/issues/461

[beeb]

Hey @aawsome , just letting you know that I haven't forgotten about this and will take a closer look in the coming weeks.

[aawsome]

Actually, on the main branch, rustic is already split into a library and GUI part. However, I'm currently about to move high-level functionality to the library. Have a look at crates/rustic_core/src/examples. However, the most important commands (init, backup, restore) are not yet moved to rustic_core. This will take another couple of days...

[beeb]

Sounds good, there is absolutely no rush on my side! I'm not yet on vacation ;)