A Simple, Sophisticated Backup Strategy
One short shell script backs up my entire home server live by relying 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 to use SQLite wherever I can, but my self-hosted stack has grown to include several Postgres instances, Redis, message queues, and more. I still wanted Time Machine-style backups with granular file history, which meant backing up often: hourly, in my case. Shutting down the stack every hour would’ve greatly inconvenienced its only user, me, so I chose to back up everything live.
I could have gone down the rabbit hole of coordinating dedicated backup tooling: a bespoke method for every service, each with its own failure modes. That would have been anything but simple. Instead, I rely on the databases’ battle-tested crash-recovery paths.
Given this assumption, the backup container is just a short shell script. Every container volume shares a Btrfs1 subvolume, so the script can take an atomic snapshot of all state. It then feeds the snapshots into Borg2, which provides incremental, deduplicated storage for local and SSH backup targets. To a database restored from one of these backups, the state is indistinguishable from that left by a power cut. My script supplies only the plumbing: configuring Btrfs and Borg, handling failures gracefully, and exposing a health-check status when human intervention is needed.
I’ve been using this since 2023. I’ve restored various files and folders and performed 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.