Disaster Recovery Test Checklist
A disaster recovery checklist for testing your DR plan: scope, failover or rebuild, RTO and RPO measurement, failback and follow-ups. Run it every quarter.
- Typical schedule quarterly
- The checklist 5 sections, 23 items
- Variables
{{scenario}}{{quarter}}
Auf Deutsch lesen: Checkliste IT-Notfalltest (Disaster Recovery)
Use this checklist to test whether you can actually recover from a disaster, not just whether a DR document exists. A disaster here means losing a whole system, region, data centre or cloud account, as opposed to restoring a single file. Run it at least once or twice a year for each critical system, and pick a different scenario each time: region outage, ransomware, deleted cloud account, lost database.
Who owns it
A DR test lead owns the run. They choose the scenario, set the rules (for example, "no access to the primary environment"), measure the times and write up the results. The people who would really do the recovery perform the steps, ideally not the same person every time.
Common pitfalls
- Testing with the author of the plan. If only one person can follow the plan, it is not a plan. Let someone else run the recovery with only the written documentation.
- Credentials stored in the system that failed. Password managers, SSO and key vaults are often part of the outage. Check that break-glass access works from outside.
- Measuring "it started" instead of "it works". Recovery time ends when users can complete a real transaction, not when the VM boots.
- Findings that never get fixed. A test without follow-up tickets only proves the same gaps again next time.
Schedule the run in Runbook every quarter. The history then shows which scenario you tested, when, and who signed off, which is useful evidence for customers and auditors.
The checklist: DR test {{quarter}}: {{scenario}}
Plan the test
-
Scenario
{{scenario}}and systems in scope written down -
Recovery time objective (RTO) and recovery point objective (RPO) for each system noted
-
Test rules agreed: what is assumed lost, what access is allowed
-
Test environment or isolated network chosen so the test cannot affect production
A live failover of production is a valid test, but only with explicit approval and a tested way back.
-
Participants, observer and timekeeper named
-
Stakeholders informed of the test window
Recover
-
Test start time recorded
-
Break-glass credentials retrieved from their offline or out-of-band location
-
Infrastructure rebuilt or failed over from the documented procedure only
Note every step where the documentation was wrong, missing or ambiguous.
-
Data restored from the most recent backup or replica
-
Application configuration, secrets and DNS pointed at the recovered environment
-
Time recorded when the first real user transaction succeeds
Measure
-
Actual recovery time compared against the RTO
-
Timestamp of the newest recovered data compared against the RPO
-
Data integrity checked: record counts, recent records, attachments and files
-
Dependencies checked: email, payments, third-party APIs, scheduled jobs
Fail back and clean up
-
Failback to the primary environment completed, if production was used optional
-
Test environment shut down and test data deleted
-
Temporary credentials rotated and access revoked
Follow up
-
Results written up: times, gaps, documentation errors
-
Follow-up tickets created with owners and due dates
-
DR plan and runbooks updated with what was learned
-
Results shared with leadership and the next scenario chosen
Checklist as Markdown
Frequently asked questions
What is the difference between a backup restore test and a DR test?
A backup restore test checks that you can get data back from a backup. A disaster recovery test checks that you can bring a whole service back to a working state: infrastructure, data, configuration, access and dependencies, within your target times. You need both, and the restore test is usually run more often.
How often should we test disaster recovery?
At least once a year for each critical system is a common baseline, and many teams test quarterly with rotating scenarios. Test again after major architecture changes, such as a new cloud provider or a new database. Contracts or frameworks you follow may set their own expectations.
What are RTO and RPO?
The recovery time objective (RTO) is the longest acceptable time until a service works again after a disaster. The recovery point objective (RPO) is the largest acceptable amount of data loss, measured in time. A DR test is the only reliable way to learn whether your real values meet these targets.
Updated