I keep a running list in a notes file called blog-todo.txt and one line has been sitting near the top since some time in 2019: "set up real backups for this thing." Seven years. That's how long a to-do item can survive on a personal blog if the site just never happens to go down. Well, it finally happened — not catastrophically, but enough of a scare last week that I actually did the thing instead of writing another paragraph about how I should do the thing.
Quick version of the scare: I was cleaning up old database dumps on the VPS to free up disk space, half paying attention while also making coffee, and I deleted a directory I meant to keep. Not the live database, thankfully, just an archive folder of manual dumps I'd been making by hand every few months whenever I remembered. Which, it turns out, was the only backup strategy this blog had. Fourteen-plus years of posts, comments, and whatever mysterious guestbook plugin I installed around 2013 and forgot to remove, all sitting on one disk with no copy anywhere else.
Nothing was lost. But my heart did a specific kind of drop that anyone who's run a server for more than a decade will recognize immediately, and I sat there for a solid minute just staring at the terminal before I even ran ls to check.
So here's what I actually set up, in case it's useful to anyone else who has a similar line sitting in their own todo file.
The backup itself. I'm using restic pointed at a cheap object storage bucket, running nightly via cron at 3:40am (picked an odd time on purpose, figured everything else on the box is more likely to be doing something on the hour or half hour). It dumps the MySQL database first with mysqldump, then backs up that dump plus the actual uploads directory. Restic handles the encryption and deduplication so I'm not paying for full copies every single night, and the incremental backups after the first one take under a minute.
The part everyone skips. I also set up a second cron job that runs weekly and actually restores the latest snapshot into a scratch directory and checks the file count against what's expected. A backup you've never tested restoring is basically a rumor. I learned this from a very grumpy sysadmin forum thread years ago and ignored the advice for a decade, so, credit where it's due, they were right.
Where it lives. This is the boring but important bit: the backups need to be somewhere that isn't the same box, obviously, and somewhere that isn't tied to the same account as everything else either, in case that whole account gets compromised or the billing lapses. I keep the VPS itself over on Tricknow since their git-push deploys make updating this blog's theme less annoying than it used to be, but the backup bucket is a completely separate provider on purpose. If one goes down or gets hacked, the other one doesn't care.
One thing I'll complain about: cron's logging is still, in 2026, an absolute mess by default. Failed job, silent as a mouse, no email, nothing — unless you go out of your way to pipe stderr somewhere and set up alerting on it. I ended up wiring a simple curl ping to a dead-man's-switch style service that emails me if it doesn't hear from the backup job within 25 hours. Cheap, dumb, works. I don't understand why this isn't just built into cron itself at this point, it's not exactly a new problem.
Total setup time was maybe two hours, most of which was spent second-guessing my own restic syntax and re-reading man pages I should honestly know by heart at this point. Compare that to what fourteen years of posts would have been worth if that folder deletion had gone one directory up instead of where it did, and two hours feels like nothing.
If your backup strategy is also "I'll remember to do it manually," go set a timer for twenty minutes right now and at least get the database dump automated. You can make it fancy later. The point is just that it happens without you.