How to Test Your Backups (and Why Most Restores Fail)

Most businesses we work with have backups. Far fewer have ever restored one. And a backup that has never been restored isn’t a control — it’s an assumption.

Why restores fail

Restore tests almost always find something. The most common findings:

• The backup job has been failing quietly, sometimes for months, and the alert goes to someone who left.
• The backup doesn’t cover everything. Files are protected; the accounting database, the email or a cloud app isn’t.
• The data comes back, but the system doesn’t start — because of a dependency, a licence key or a configuration nobody wrote down.
• The database restores, but it’s missing recent writes, because it was copied while in use.
• The backups were reachable from the network and would have been encrypted along with everything else in a ransomware attack.
• The restore takes far longer than anyone assumed. Twelve hours, not two.

None of these is exotic. All of them are much better discovered on a planned Wednesday than in the middle of an incident.

How to run a restore test

1. Pick one critical system. The file server, the accounting database, a key mailbox.
2. Restore it into an isolated environment — somewhere that can’t reach or overwrite the live system.
3. Start a timer. Record how long each step genuinely takes.
4. Verify the result. Don’t just confirm files exist: open them, run the application, check that the newest records are there.
5. Write down every surprise — missing steps, missing passwords, dependencies nobody mentioned.
6. Turn it into a runbook that someone other than you could follow.

The number that matters

At the end, you have one figure: how long it actually takes to get back to work. Compare it with how long the business can afford to be down (your RTO) and how much recent data it can afford to lose (your RPO). If they don’t match, you now know exactly what to fix — before it matters.

How often

• A full restore of each critical system at least once a year.
• Spot checks — a single folder or mailbox — more often.
• After every significant change: a new server, a new backup tool, a migration. That’s when backups most often break silently.

If you’ve read this far and aren’t sure your backups would restore, that’s the situation in we don’t really have a backup system. Restore testing is part of our infrastructure and backup practice.