After much hemming and hawing I have finally, finally settled on a suitable 3-2-1 backup plan that works for my budget, runs unattended, alerts me when there's a problem, and only uses programs and services that I don't find objectionable. That's a lot to pack into one sentence, so let's break it down.
My entire backup strategy is based around Borgmatic. After looking into a number of options, including a custom script, vanilla borg, restic, rclone, and a few others, I determined that Borgmatic was going to be the most configurable and most hands-off solution that would reliably work for my needs.
Borgmatic uses a .yaml-based configuration, which is cool with me. In a minimal configuration, you will choose the directories you want to include in your backups ("source directories") and the destinations that the source directories will be backed up to ("repositories"). To achieve a satisfactory level of backup redundancy, you'll want at least two, and so in my setup, I have two repositories configured: one to a secondary hard disk on my NAS, and one to my remote backup host of choice, rsync.net.
I did a lot of shopping around before settling on rsync.net, and so far I'm very happy with my choice - they're rather small, very stable, and have been providing the same excellent and focused service for something like 25 years. They feel like the mom and pop shop of remote storage providers. Are they a little more expensive than the major cloud providers, or the endless list of AWS S3 resellers? Sure, but it's worth it to me to avoid those other guys. By the way, if you're interested in using them, rsync.net offers significant discounts to power users that are mainly interested in the offsite backup use case that I selected them for.
Ok, what else do I like about Borgmatic? Backups are fully encrypted locally, before being pushed to a repository. That, in my view, is mandatory, no matter how much you may trust a storage provider. Borgmagic can easily be configured to retain multiple versions of your backups, in case you accidentally deleted something you need and only learn about it months later. In my case, I keep 7 days, 4 weeks, 6 months, and 1 year of backup versioning. Is this really needed? Probably not, but it's basically free, so why not? The tool implements de-duplication support, so versioned backups barely consume additional disk space in your repositories. Finally, Borgmatic supports a number if different "hooks", effectively making it easy to take various actions when your backups succeed, fail, or move through different phases of the backup process.
In my configuration, I have a "success" hook configured to ping healthchecks.io when my backups complete, and an "error" hook to ping ntfy.sh when my backups fail. The premise of healthchecks.io is that it will alert you if one of your services *doesn't* check in for some configurable period of time; ntfy.sh does the opposite: if my backup reports an error, it will email me, ping my phone, or whatever. Point being, other than testing the restore process occasionally, I don't need to manually monitor these backups at all.
One thing that Borgmatic doesn't handle itself is the actual scheduling of the backup. Previously I've just used cron for stuff like this, and it's worked fine; this time around I wanted to try a systemd timer that wraps my Borgmatic backup command in a lock that's managed by flock. That way, I get a "catchup" backup in the case of downtime during the normal backup period, and flock ensures that long-running backups won't stack up or overlap. Is this added complexity really necessary? In my opinion, for my use case, it isn't. This was done more as a fun learning exercise than because of any real need. Happy crontab users that don't feel like tinkering should just keep doing that, IMO.
Anyway, I was dragging my feet a little bit on my backup plan, because it took me a long time and a lot of research to figure out what I really wanted to do. Once I made the needed decisions, though, I had a ton of fun implementing everything, and learned a lot along the way. Best of all, I have a robust plan in place to ensure that my data is safe and secure without any ongoing effort on my part.
~nullish
---