Backups you have never restored are not backups
A practical restore-testing routine that fits in an hour a month and turns a hope into a guarantee.
Backup software reports success far more often than it delivers a working restore. Files can be captured mid-write, a database dump can be truncated, encryption keys can be lost, and retention windows can silently be shorter than the time it takes to notice a problem. The only way to know is to restore.
Know your two numbers
Recovery point objective is how much data you can afford to lose — the gap between backups. Recovery time objective is how long you can afford to be down. Agree both with the business, in writing, before you design anything. A store during peak trading and an internal wiki deserve very different answers.
The monthly hour
A restore drill does not need to be elaborate. Ours looks like this.
- Pick a random backup from the last 30 days, not the newest one.
- Restore it into an isolated environment with no access to production or live payment credentials.
- Load the site, sign in, and check that recent records exist in the database.
- Record how long the restore took end to end, and compare it to the agreed recovery time objective.
- Note anything manual you had to do, and automate one of those steps before the next drill.
Protect the backups themselves
Ransomware targets backups first. Keep at least one copy that production credentials cannot delete — a separate account, immutable storage, or offline retention. Encrypt copies at rest and store the keys somewhere independent of the system being backed up.
An untested backup is a hope with a filename. One hour a month converts it into a number you can quote to the board with confidence.
Talk to our team
