Restic support (work in progress)

[carlonluca]

This is a work in progress of the implementation of restic support into Kup as per #54. There are a few critical points:

• backup is done similarly to bup. No idea if restic keeps the output unaltered from one version to another, hope so. This portion seems to work on my docker development container. I added support for exclusion but that needs to be tested.
• I'm working on support for file digger, which is a bit more complex, requires many more changes. Will commit my proposal in another PM. I added instead a different view of the backup, which I called temporarily "backup explorer". It shows snapshots. The idea is that the user can freely browse with any file manager, being also able to restore whatever he wants. Particular attention is needed when the backup needs to be unmounted. This is however a view that differs from the one of file digger, but may be useful if ability to remove snapshots was added in the future. Restic provides that feature. Choice to implement this is that it is simpler to file digger but provides a way to access backup data.
• Backup password is temporarily hardcoded. It can probably be set somewhere in the settings and saved in kwallet?
• Tests are needed. I only tested quickly on Neon with a development version of Plasma. If someone is interested in helping, bug reports are welcome.

I'm open to suggestions. I'd personally consider these the minimal set of features to make restic support of some use. Any help is welcome!

[spersson]

Oh wow, impressive work!

I just spent a couple of hours reading restic documentation and reading your code. Here are my thoughts.

I don't see any advantage to restic over bup, except possibly that adding support for encryption could be easier with restic. Otherwise the two softwares are almost identical. Restic lacks support for adding redundacy information and fixing broken backups, I think? So I stand by my comment on #54 that this backend could be used as a fallback in case bup is not installed but restic is. Of course if experience later shows that restic is overall the better choice we could reverse the priority order.

I see no problem with merging this with just default password, effectively disabling encryption. Later we can always add encryption to both bup and restic, if desired.

One possibility that we need to decide how to handle is that user selects versioned backup for his plan and bup is available the first time that a backup save job runs. That means a bup repo gets created at the destination. If later bup is not available we need to detect that the destination already has a bup repo and not just switch to using restic for saving. Maybe we just show an error message and abort then.

For restoring it would be nice to have filedigger working for both. If possible. Please investigate how it could be done to get a list of unique timestamps for a given file or folder. The QAbstractItemModel can make use of the canFetchMore() thing to do lazy exploring of the backup repo.

I think it should be OK to not do a kioslave for restic, instead just fuse mount the backup like you currently do.

I think you can continue working on your branch and we wait with merging this PR until we are happy with the whole thing. I will look more at details of the code when the overall feature set looks good.

Thank you!

[carlonluca]

Actually, one of the reasons I'm not using bup at the moment is: "bup only has experimental support for pruning old backups". No way to recycle space safely is a no-go for me. I'm stuck with rsync when using Kup.
However I agree, features are similar. It is just a different backend that someone may need to handle his own backups, if he is using restic already maybe. That is why I was thinking it more like: bup is the default for versioned backups, restic is an option if someone intentionally needs or wants restic. Someone can prefer one or the other, may already have a restic repo or similar. Restic seems to be pretty popular.

I already have some code ready to support file digger. I can include in this PM then. I cannot create another PM I guess cause it relies on this one.

[carlonluca]

I kept working on this patch and at the moment I think we have most of what we need. The patch is not ready yet, much testing is needed, but most of the features are implemented, and I added some others:

• selection of Restic backup type (bup remains the default);
• I added some custom options for Restic that I think could be a good improvement for Kup: old data can be recycled according to several policies, Restic allows this and is considered stable.
• backup procedure is implemented in the daemon;
• notifications are implemented, although logs should be improved;
• cleanup is implemented as part of the backup procedure (this is something that should be discussed) and includes notifications as well;
• the separate app I created to list the snapshots was completely removed and the code is instead merged into filedigger;
• filedigger now supports Restic;
• filedigger includes a new tab that shows each snapshot: this is useful because the user can even browse a specific snapshot using dolphin and open files like it was a regular filesystem. This is implemented both for Restic and Bup.

This patch includes a draft of abstraction of each component, which is then implemented for Bup and for Restic. This should make it simpler to add other backup systems in the future.
I'll use this for some time to test it on my own backups, I'll keep fixing and improving the code, until it is ready.

[enboig]

I am really interested in restic support. I was looking for dummy remote repository, and restic has it. It lack compression, but you can share a repository between computers, which is better in my case.