How to test a restore properly
Restore testing has a reputation for being disruptive. Done properly it touches nothing in production and takes an afternoon.
Three levels, increasing in value
File level. Pick a document, restore it somewhere temporary, open it. Ten minutes. Catches corrupt backups and expired credentials. Do this monthly.
Application level. Restore a database or a mailbox to a test environment and confirm the application actually starts against it. Half a day. Catches the failures a file restore never will — missing dependencies, encryption keys nobody kept, a version mismatch. Do this quarterly.
Full recovery. Rebuild a critical server from nothing in an isolated network. A day. This is the only test that produces a real recovery time. Do this once a year and after any significant change.
Write down two numbers
Every test should produce:
- Recovery time — how long from starting to a working system
- Recovery point — how much work was lost, measured from the last usable backup
Those two numbers are your actual disaster recovery plan. Everything else is documentation around them.
The failures a test finds
In practice, tests fail for reasons nobody predicted:
- The encryption key was stored only on the server being restored
- The backup captured the database files while the database was mid-write
- Restoring took eleven hours, and the plan assumed two
- The licence needs reactivating and the vendor portal login left with an ex-employee
- The documented procedure refers to a console that was replaced last year
Each of those is trivial to fix on a quiet Tuesday and catastrophic to discover on the worst morning of the year.
Make it routine
Put it in the calendar, give it an owner, and keep a one-page log: date, what was restored, how long it took, what broke. After a year that log is the most useful document in your IT estate.
The question is never whether the backup ran. It is how long you would be down, and you cannot answer that without measuring it.
We run restore tests as part of servers and backup.