Backup Restore Test Checklist
A backup checklist for real restore tests: pick a sample, restore it in isolation, verify the data, record timings and fix gaps. Schedule it every month.
- Typical schedule monthly
- The checklist 4 sections, 18 items
- Variables
{{system}}{{month}}
Auf Deutsch lesen: Checkliste Backup-Test (Wiederherstellung prüfen)
A backup you have never restored is a hope, not a backup. Use this checklist to prove, on a regular schedule, that you can get data back from your backups within an acceptable time. It covers one system per run, such as a database, a file share, a SaaS export or a server image. Rotate the system you test each month so everything important is covered over the year.
Who owns it
A named engineer owns each run and performs the restore. Ideally it is not always the person who set up the backups, because a restore test is also a test of the documentation. The system owner confirms that the restored data is correct and complete.
Common pitfalls
- Testing only that the file exists. A backup file can be present and still be corrupt, empty or encrypted with a key nobody has. Restore it and open the data.
- Restoring over production. Always restore into an isolated location. Restoring a test copy over the live database is a classic way to cause the outage you were preparing for.
- Forgetting what is not in the backup. Encryption keys, configuration, secrets and SaaS data (e.g. Google Workspace, Microsoft 365, GitHub) are often outside the main backup job.
- Never timing it. A restore that takes a day may be too slow for your recovery targets.
Schedule the run monthly in Runbook. Each completed run, with its timings, is a dated record that restores were tested.
The checklist: Backup restore test: {{system}} ({{month}})
Prepare
-
Backup to restore chosen: latest copy of
{{system}}, plus one older copy optionalTesting an older copy as well confirms that retention works and older backups are still readable.
-
Isolated restore target ready: separate server, database instance or bucket
-
Restore procedure for
{{system}}found in the documentation -
Decryption keys and credentials available to the person doing the restore
Restore
-
Start time recorded
-
Backup copied or mounted from its storage location, including off-site or immutable copies where used
-
Restore completed without errors
-
End time recorded and total restore duration noted
Verify the data
-
Restored data opens or starts: database accepts queries, files open, application boots
-
Record counts or file counts compared with production at backup time
-
Most recent records checked, and the backup age matches the expected schedule
-
Sample of specific records or files checked by the system owner
-
Integrity checks run where available, e.g. database consistency checks or checksums optional
Clean up and record
-
Restored copy deleted or access-restricted, since it contains production data
-
Restore duration compared with the recovery time target for
{{system}} -
Documentation corrected where the procedure was wrong or unclear
-
Problems found logged as tickets with owners
-
Next system to test chosen for the following month
Checklist as Markdown
Frequently asked questions
How often should backups be tested?
Test restores on a regular schedule, for example one system per month in rotation, so that every critical system is tested several times a year. Test again after any change to the backup setup, such as a new tool, storage location or encryption key. Automated restore checks are a good addition but do not replace a human looking at the data.
What is the difference between backup verification and a restore test?
Backup verification usually means checking that a job finished and the file is intact, for example with checksums. A restore test actually brings the data back into a working system and checks that it is usable. Only the restore test shows that you can recover in practice.
What should a backup checklist cover besides restores?
Check that every important system is included, that copies are kept off-site or immutable, that retention matches your needs and that keys are stored separately from the data. Do not forget SaaS data and configuration. Restore tests then confirm that all of this actually works.
Updated