Test backup recovery quarterly: perform a simulated full restore, time the process, document gaps — untested backups are Schrödinger's data
Test one backup quarterly by performing a simulated full restore to verify recoverability before you need it, timing the process and documenting any gaps.
Why This Is a Rule
A backup that hasn't been tested is an assumption, not a protection. You assume the backup is complete, assume the files aren't corrupted, assume the restore process works, and assume it can be completed in a reasonable timeframe. Each assumption may be wrong, and you'll discover it at the worst possible moment — when you actually need the backup because your primary data is gone.
The quarterly restore test converts assumptions into verified facts. Actually restoring data reveals: Completeness gaps (files that weren't included in the backup scope), Corruption (files that backed up but can't be opened), Process errors (the restore procedure doesn't work as documented), and Time requirements (restoring takes 8 hours, not the 30 minutes you imagined). Discovering these during a quarterly test gives you time to fix them. Discovering them during an actual disaster means your backup has failed at the moment of maximum consequence.
The "Schrödinger's backup" concept: your backup is simultaneously working and not-working until you test it. The quarterly test collapses the uncertainty into a known state — either it works (confidence), or it doesn't (fixable before disaster).
When This Fires
- Quarterly, as a scheduled maintenance activity
- After any changes to backup configuration (new tool, new location, new scope)
- When you realize you haven't verified backup recoverability in 6+ months
- Complements 3-2-1 backup rule: 3 copies of critical data, on 2 different media types, with 1 stored offsite — redundancy protects against correlated failures (3-2-1 backup rule) with the verification that the backup infrastructure actually works
Common Failure Mode
Backup-without-verify: running automated backups daily for years without ever testing whether the data can actually be restored. The backup process runs, the status says "complete," and you assume you're protected. Meanwhile, the backup has been silently failing to capture a critical directory, or the cloud restore process requires a password you've since forgotten.
The Protocol
(1) Quarterly, select one of your backup copies (rotate between copies across quarters). (2) Perform a simulated full restore to a temporary location (not overwriting your current data). (3) Time the process from initiation to completion — this is your recovery time. (4) Verify the restored data: open representative files from each critical data category. Check formatting, metadata, and file integrity. (5) Document: What worked (successfully restored data types), What failed (missing files, corruption, process errors), Time taken (your actual recovery time), Gaps (data that should be backed up but wasn't). (6) Fix any identified gaps before the next quarter.