Simple, Sophisticated Backup Strategy
One short shell script backs up my whole home server live: betting on crash recovery instead of per-database tooling.
The more critical a system is, the simpler it should be. In practice, that means building on battle-tested foundations, and adding only the thin layer of logic that you absolutely must have.
My home server’s backup is a good example. I aim for SQLite wherever I can, but reality has added multiple Postgres instances, Redis, message queues, and so on to my self-hosted stack. I still wanted time-machine-style backups with granular file history, which means backing up often (hourly, in my case). But shutting down the stack every hour would’ve greatly inconvenienced my only user (myself), so the only solution was to back up everything live.
I could have gone down the rabbit hole of coordinating each database’s dedicated backup tooling: one bespoke method per service, each with its own failure modes. That would have been anything but simple. Instead I rely on serious databases having a battle-tested crash recovery path.
With this assumption, the backup container turns out to be just a short shell script. Every container volume lives on a btrfs1 subvolume, so the script can take an atomic snapshot of each. The snapshots are then fed into borg2, which handles incrementality and deduplication across local and SSH backup targets. To a database restored from this backup, the state is indistinguishable from a power cut. My backup script’s contribution is just the plumbing: configuring btrfs and borg, handling failures gracefully, and maintaining a healthcheck status for when human intervention is needed.
I’ve been using this since 2023; I’ve restored various files and folders and done two full disaster recoveries. Nothing builds confidence like a restore that works: borg, btrfs, and this little script have earned their keep, and I don’t expect to migrate away any time soon.