A Backup You've Never Restored Is Just a Hope

Why untested backups fail small teams, and a practical restore-testing routine that catches broken dumps before a real disaster does.

Almost every team has backups. Far fewer have ever restored one. That gap is where disasters live: the cron job that silently stopped months ago, the dump that's missing a schema, the archive that's encrypted with a key nobody can find. The uncomfortable truth is that a backup only exists the moment you successfully restore it. Everything before that is a hope.

Why backups quietly rot

Backups fail in boring, predictable ways, and almost never announce themselves:

• Silent job failures. The cron entry runs, exits non-zero, and nobody is watching the exit code. Weeks of "backups" are zero-byte files.
• Schema drift. Your restore scripts assume tables and extensions that no longer match production, so the dump imports with errors nobody reads.
• Missing pieces. The database is backed up, but uploaded files, environment configs, or the encryption keys needed to decrypt the archive are not.
• Wrong retention. Everything overwrites yesterday's copy, so a corruption discovered on Friday has already been faithfully backed up on top of the good data.

None of these show up in a dashboard. They show up at 2 a.m., during the one incident where you actually need the backup.

Restore is the product, backup is the byproduct

Flip the mental model. Don't ask "are we backing up?" Ask "how fast can we get a working system from nothing?" That question forces you to define two numbers, even informally:

• How much data can we afford to lose? That sets your backup frequency. If losing a day of sales records is unacceptable, nightly dumps aren't enough.
• How long can we afford to be down? That sets how automated and rehearsed your restore needs to be.

For a small business system — a POS backend, a messaging service, an internal API — honest answers are often "an hour of data" and "half a day of downtime." That's fine. What's not fine is never having asked.

A restore drill you'll actually do

The reason teams skip restore testing is that it sounds like a big ceremony. Make it small enough to be routine:

1. Automate the restore path first. One script that takes the latest backup and stands up a database on a scratch server or container. If the restore requires tribal knowledge, it will fail when the person holding it is on vacation.
2. Verify, don't just import. After restoring, run a few cheap sanity queries: row counts on critical tables, the timestamp of the most recent record, a checksum if you have one. A restore that completes but contains last month's data is still a failure.
3. Schedule it monthly. Put it on the calendar like a deploy. Thirty minutes, once a month, is the entire cost.
4. Alert on the backup job itself. The job should ping a dead-man's-switch monitor on success. Silence — not an error — is the alert.

If your restore procedure is a wiki page last edited two years ago, you don't have a procedure. You have archaeology.

Keep copies where the disaster isn't

One backup on the same server protects you from a bad DELETE, not from a dead disk or a compromised machine. The classic 3-2-1 guidance still holds for small teams: keep more than one copy, on more than one kind of storage, with at least one copy off the server entirely — object storage in another region is cheap and effortless. Encrypt it, and store the key somewhere that survives the same disaster.

The takeaway

Backups are not a checkbox; restores are. Automate the restore, verify the data, rehearse it monthly, and alert on silence. The first time you run a restore should never be the day you need one.