search

enzingerm / snapborg

Synchronize snapper snapshots to a borg repository
GNU General Public License v3.0
35 stars 6 forks source link

Autoprune [1/6] #7

Closed jrabinow closed 2 years ago

jrabinow commented 2 years ago

Snapborg autoprunes after backing up latest batch of snapshots.

Use the --no-prune flag to disable this behavior.

jrabinow commented 2 years ago

I see snapborg as eventually having the exact same interface as borgmatic, and as such I tried to stay as close to borgmatic's user experience as possible. Running a few tests, I found that borgmatic auto-prunes by default - pruning is one of the default actions at runtime. I can see why they did things that way: users have to specify a retention policy, the tool may as well act on it - in fact, I'd argue that according to the principle of least surprise, specifying a retention policy and not having it automatically acted upon is kinda surprising. Why make users remember to run 2 commands when a single command works?

I'd like to make sure you know about these arguments. If they aren't enough to convince you, I'll switch things around to how you requested.

enzingerm commented 2 years ago

Even if borg prune is not invoked, snapborg already acts on the specified retention policy during backup: it uses it to calculate which snapper snapshots it should choose to actually back up. This is not that relevant when snapborg is run periodically in a short interval, because it will transfer the most recent snapshot(s) (older snapshots would already have been transferred by an earlier invocation of snapborg). However, in my original use case the backup target (ext. HDD) might not be accessible permanently and I wanted snapborg to also transfer one snapshot for all the previous days if the HDD was plugged in from time to time. This is also the reason for the "fault tolerant mode" which can be activated in the config.

One can now argue why snapborg uses its own retention policy and does not leave the task of thinning out the snapshots to snapper itself and its timeline cleanup algorithm. But my thought was that I would like to have more "dense" snapshots on the live machine and only transfer a subset of those to the borg repository. And I wanted to have older snapshots in the borg repo which don't need to be kept on the live machine.

Coming back to this PR, I understand the point and as snapborg is already more than just a simple wrapper around borg (it acts on multiple configs/repos and snapshots at once), it is already quite close to borgmatic. So yes, let's leave the switch as you suggested. But please mention it in the README in the Usage section as a parameter to the backup subcommand.

jrabinow commented 2 years ago

It sounds like we have a very similar, if not identical, setup/usecase.

Good catch with the README, I've updated it too.

I'm wondering if it's worthwhile to have the PKGBUILD print a message saying that pruning now happens by default, so that any existing users aren't caught off guard.

Another option is to make the decision to go full borgmatic and not merge this PR in until the rest of the tool's interface (command-line interface, config file) are made as similar as possible to borgmatic's. I must say however it's quite unlikely that I get around to reworking the command-line/config file: once this set of PRs are all merged in, the script will have the functionality that I'm looking for, making the tool into a fully borgmatic-like/borgmatic-compatible tool are not on my personal agenda.

I've created a new issue for you to look into, if you don't feel like pursuing that train of thought, feel free to close it.

In the meantime:

enzingerm commented 2 years ago

About the PKGBUILD, I don't think there is a userbase yet which could be caught off-guard by this. And even so, pruning is something you would want to do once in a while anyways.

Concerning the Borgmatic like interface, this would be for sure a cool thing, especially for things like hooks or automatic consistency checks. But this is also not something which I would want to implement by myself, as the tool already does what I want it to do. The corresponding issue can stay open and if someone feels motivated, he can do it.