A backup you have never restored is a wish, not a backup

The night this site went public I finally built the thing I had been putting off for weeks: proper backups. Not because going public makes data loss more likely, but because it made me look at the site the way you look at something you could now actually lose. People have accounts here. There are forum posts and stories that exist nowhere else. Losing my own tinkering is a shrug; losing someone else's words is a betrayal. This build log is about the backup system, and about the one step almost everyone skips, which is the only step that matters.

What most people call a backup

The usual story goes like this. You set up a scheduled task that copies your data somewhere every night. It runs, it produces files with reassuring timestamps, and you feel responsible and move on with your life. Months later, the day arrives when you need one. You open the most recent file and discover it is empty, or truncated, or encrypted with a key that only ever existed on the machine that just died, or perfectly valid but missing the one table that mattered because of a setting you changed last spring.

Every experienced sysadmin has either lived this or watched it happen to someone. The pattern is always the same: the making of backups was automated, and the checking of them was left to a human. To a future human, in fact, who was assumed to be diligent. I have ADHD. I know precisely how much my future self can be trusted with a recurring boring task that produces no visible result. He is a lovely man but he will not be doing it.

A backup you have never restored is a wish

So the rule I built this around: until you have taken a backup and actually restored it, and seen your data come back with your own eyes, you do not have a backup. You have a wish with a timestamp on it.

Here is what runs every night while I am asleep, in plain terms:

1. Dump. The database writes a complete copy of itself out to a file: every account, post, story and setting.
2. Encrypt. That file is scrambled before it goes anywhere, so a copy falling into the wrong hands is a nuisance rather than a breach. The key lives separately from the backups, because an encrypted backup stored next to its own key is just a backup with extra steps.
3. Move it off the machine. A copy that lives on the same disk as the original protects you from exactly nothing that matters. Disks fail as a unit. The copies go to separate storage, and older ones are pruned so it keeps a couple of weeks of history rather than growing forever.
4. Now the important one: restore it. The same nightly routine takes the backup it just made, decrypts it, and loads it into a scratch database, a disposable one, completely separate from the real site. Then it counts what came back: are the accounts there, are the posts there, are the numbers sane compared with the live site? Only if the restored copy passes does the night count as a success. Then the scratch copy is thrown away.
5. Complain loudly on failure. If any step fails, I get a message on my phone. Silence means it worked. A backup system that fails silently is worse than none, because it also switches off your worry.

Step 4 is the whole article. Steps 1 to 3 make backups; step 4 makes them true. It converts "I believe I have backups" into "a restore succeeded nine hours ago", and those are different sentences in the way that matters at 2am. The dress rehearsal happens every single night, so opening night, if it ever comes, is just another Tuesday.

The neurodivergent bit, because there always is one

The standard advice is "test your backups regularly", filed alongside floss daily and review your insurance. It assumes a person who does scheduled maintenance out of pure conscientiousness. I am not that person. On my honest days I know I never will be, and decades of unflossed evidence back me up.

The accommodation is the same one I keep reaching for in this build: don't rely on remembering; make forgetting safe. I did the careful thinking once, on a good day, and poured it into a script. The script does not have good days and bad days. It does not get bored of a task because the task stopped being novel. The discipline is in the walls now, not in me, and the walls remember so I don't have to.

If you have ever felt guilt about being unable to sustain a routine that other people apparently manage, I would gently offer this reframe: the sysadmins whose backups actually restore are not the ones with the best memory. They are the ones who stopped trusting their memory and automated the proof. That is not a workaround for a deficient brain. It is just good engineering, and my brain simply refuses to let me pretend otherwise.

Try it on your own stuff

You do not need a server or a website for the principle to pay rent. Pick one thing you believe is backed up, your photos, your documents, the novel, and restore one file from it today, all the way, until you can open it. Either you get a small warm feeling of genuine safety, or you find out now, while it is a to-do item rather than a disaster. Both outcomes are wins. The only losing move is the wish.