Borgbackup

[tasosalvas]

debops.borgbackup

Hey there all, I'm back from the dead! Love the new CLI and modern layout. I hope to keep in touch, although I already have to pace myself after spending a couple of weeks (I'm slow) on this.

This PR is based on #2434 by @Alphix, which in turn was based on #835 by @ypid.
I've kept their credit lines on all files (tell me if I missed something), and I'd love their feedback.

I have reworked the role so it's simpler to deploy, test and hopefully review. Mostly I cut things and exposed what was left in documentation and inventory. All functionality is still there, although a bit more of it is deferred to dependent debops roles.

Flow

The original Alphix PR implemented a network of four classes of hosts, running inventory-wide checks before it deployed anything.

I wanted it to be:

• able to configure a single host at a time
• usable as a dependent role
• able to work with hosts not in inventory (very common with borg hosting services)

The classes have little to do with each other and there are valid use cases for having a host belong to multiple of them, so I deferred the whole issue to inventory variables and documentation.

Configuration

Borgmatic is configured with yaml, and the old role contained what could be described as a full yaml parser for universal configuration. Alphix had mentioned it had some issue needed fixing, I found it horrifying and cut it out.

Thing is, borgmatic already has units and supports a whole system of includes, overrides, even constants in newer versions.

• Borgmatic: How to make per-application backups

The re-written configuration scheme supports _kv items that output atomic yaml files, through | to_nice_yaml or raw. There are helpers to prepopulate some values, link them together and to initialize repositories, the output gets validated, that is all. Enough rope.

This is exposed to inventory as borgbackup__*_configuration, letting inventory add its own repos and configs as borg intended.

There's also borgbackup__server_*_accounts, allowing adding repo users to existing servers.

Version Checks

The way from debian's borgmatic 1.7.7 to the current 1.8.x is paved with syntax and CLI changes. Users upgrading from one to the other will need to adapt their inventory configurations anyway, and several features between those versions change what even the best implementation approach is.

The role has multiple specific version checks to adapt to missing features, changed binary names and old syntax, so that it may be used with a newer binary (and an adapted inventory) if needed.

All the checks have version in a comment near them and are designed to be easy to rip out after bookworm is done.

That's it

I'm not sure I had to do a single admin thing, it was all laid out already by Ypid and Alphix. I have tested every bit of functionality and outputted config (uh except cron), adapted a few things here or there, but mostly just packaging. Butchering and packaging :)

Feedback welcome!

Any, really. Some stuff I was wondering about:

• The role jumps through a lot of hoops to work with cron, in case systemd is not installed. It's a much less secure implementation. I would happily rip it out
• All of the (ton of) dependent roles are loaded conditionally across four installation profile groups, leaving the role playbook with a single invocation of the role itself. Is that too opaque?
• The recommended borgmatic installation is via root's pipx. I don't hate it. Do we like it? It would make following the current doc much less nasty user-side compared to bookworm's