Systemd units

[dflemstr]

I found it useful to have these systemd units for regularly running snapborg on my computer.

The only caveat is that it runs the snapborg commands as root, so the root account needs to have the right SSH keys and such to access the borg server. I also haven't tested this setup with encryption schemes that require an interactive password.

[enzingerm]

Thanks very much for this PR! Will be very useful so that people don't need to write their own custom scripts/systemd units. I think the unit files would better be placed under /usr/lib/systemd/system as snapborg can be considered installed software and /etc/systemd/system is more for custom units defined by the system administrator. System administrators/users can modify the unit files anyway by using systemctl edit. As I don't know too much about setuptools, I am wondering if we can always expect the executable script to be /usr/bin/snapborg?

[dflemstr]

I think the unit files would better be placed under /usr/lib/systemd/system as snapborg can be considered installed software and /etc/systemd/system is more for custom units defined by the system administrator.

Ah, of course, my bad! I'll fix that.

As I don't know too much about setuptools, I am wondering if we can always expect the executable script to be /usr/bin/snapborg?

Hmm, yeah maybe not. I'll investigate if there are any good alternatives for inserting the right path dynamically.

[dflemstr]

I found no clean fix for making the path to the snapborg script be dynamic. I think this might have to be a thing that gets fixed by the distro packager. Considering a few scenarios:

• If installing snapborg in a venv, or in user scope, a lot of the stuff here would need to change. For example, the systemd units would have to be installed in the users' ~/.local/share/systemd/user/ folder; not sure how that would work with multiple venvs though... I would argue this should be "not supported"
• Installing using setuptools globally on a system is discouraged and even blocked on many distros (including Arch for example; ie installing global python packages is completely blocked/forbidden by pip and other package managers).
• Installing using the distro's native package manager should reasonably install into /usr or /opt, and I think one can be opinionated and pick /usr in this case.
• Some distros like nixos would need to put the files under the right /nix/... path, but I believe that even nixos creates symlinks in /usr/bin for compatibility

[enzingerm]

Thanks for your research, I agree that this task can be left to the packager.

One think which I noticed is that the unit files are split into backup and prune, which implies that pruning is being separated from the backup process. However, snapborg backup does pruning by default. Maybe the --no-prune flag should be added to the backup unit files.

[dflemstr]

Ah, I didn't catch that pruning was done during backup! Sure, I can add the --no-prune flag. For my own backup policies, I was naively thinking that I would need to do pruning more often than backups, but maybe that's not the case/premature optimization.

I would also be fine with simply deleting the prune units tbh

[enzingerm]

I'm not quite sure what you mean by "pruning more often than backups". If snapborg wouldn't prune by default (as you expected its behaviour to be like), and you ran multiple prune invocations at different times in between two backups, you could have just reduced this to one single invocation (the latest one) with the same end result. But yes, multiple prune invocations with no backup in between would result in a more progressive release of disk space. In most cases backup and prune can go together, but for data which is not regularly changed and for which it might not be neccessary to make very regular backups, running prune separately can thin out the remaining backups and free space progressively.

Maybe the important question is whether someone might want to backup without prune. I think this would defeat the whole purpose of the retention settings, so maybe the backup units should still prune (but maybe add a hint to the implicit pruning?).

[dflemstr]

I guess my previous thought was based on the fact that systemd timers need to be ran at a regular interval, but the cleanup policies might lead to a non-regular cleanup pattern. Or in other words, as far as I know it's not possible to create a timer that only schedules that last prune run without also running prune in between now and then at a regular interval.

But as I mentioned, maybe it is premature optimization. I think my preference would be towards removing the prune units, but in lieu of that I'm also fine with clarifying the description in the backup units to mention that they do pruning too.

[enzingerm]

I agree that it's maybe best to remove the prune units especially considering that the timers would fire in the same interval as the backup units. Otherwise, this looks good!

By the way, I'm already enjoying significantly reduced backup times of my servers due to the bind mount patch (from >10hrs to 20min) :clap: I enjoy seeing even small projects like this getting improved by such valuable contributions, thank you very much! (although I'm dreaming of rewriting this in Rust for a more stable and predictable behaviour and to refresh and improve my rusty, basic rust skills)

[dflemstr]

I'd be happy to help with a Rust rewrite, I have some experience in that regard.

For now, prune units are removed!

[enzingerm]

Thanks! Regarding the Rust rewrite, I'd be happy if someone with more experience in Rust would contribute! As I've already started playing around with it, the next step would be to upload the project to Github and maybe create an issue with a link in it in the snapborg repo. Hope I'll get to this the next few days :)