A Backup You've Never Restored Isn't a Backup

The worst backup story I know isn't the business that had none. It's the one that had them for two years, went to use one after a bad day, and found every copy was empty. The job had been running the whole time. Somewhere along the way it had quietly started saving nothing, and nobody was watching closely enough to notice.

That's the thing about backups. They fail politely. Nothing breaks, no alarm goes off, the little "backup complete" note still turns up. The failure only surfaces on the one day you actually reach for the copy, which is the worst possible day to learn it was never really there.

A backup running is not a backup working

When someone says "don't worry, it's backed up," what they usually mean is that a backup job is scheduled and it isn't throwing errors. That sounds like safety. It isn't quite.

A backup job can run perfectly and still save a broken copy. It can back up the wrong thing, or half the thing, or an empty version of the thing, and report success every time, because it did technically run. Unless someone is checking what actually landed in those copies, "the backup ran" and "we have a copy we can use" are two different statements, and only one of them helps you when the server dies.

The restore is the only proof

Here's the rule that cuts through all of it: you don't have a backup until you've restored one. Everything before that is a hope with a filename.

Restoring is taking one of those copies and actually rebuilding from it, checking that the site comes back and the data is all there. It's the only test that proves the whole chain works, the saving, the storing, and the getting-it-back-out. Plenty of businesses have a beautiful shelf of backups and have never once taken a copy down to see if it opens. Until someone has, you don't know you have a safety net. You know you have something that's shaped like one.

I learned this from the building side, and it stuck hard enough that I wrote a piece called Restores Are Harder Than Backups after living it. You don't need the technical version. You just need the same conclusion: the restore, not the backup, is the part that actually saves you.

Where "backed up" quietly goes wrong

Even a working backup can be undone by where it lives. The classic mistake is keeping the only copy in the same place as the original, on the same server as the site itself. That feels backed up, right up until the server fails and takes the site and its only backup down together in one move.

The plain-language version of doing it right is simple: more than one copy, in more than one place. A copy on the server is convenient for small mistakes. A copy somewhere completely separate is what saves you when the whole thing goes down. You don't need to run any of this yourself. You just need to know that "there's a backup on the server" and "we could survive losing the server" are not the same sentence.

The one question that reveals the truth

You can't audit a backup system, and you shouldn't try. But you can ask one question that quietly tells you almost everything: has anyone ever actually restored one of our backups, and did it work?

Listen to the answer. "Yes, we tested a restore in [some real month] and it came back clean" is the answer of someone who has checked. "It's all backed up automatically" is not an answer to the question you asked, and the gap between the two is exactly where businesses get hurt. If nobody can remember ever restoring one, that isn't proof it's broken, but it does mean nobody actually knows, and not knowing is the state most of these stories start in.

Backups are the promise that a bad day stays a bad day instead of becoming the end of the business. But the promise is only real once someone has cashed it at least once, on purpose, when nothing was wrong. Ask when that last happened. If the answer is "never," you've just found the most valuable hour of work anyone could do on your project this month.