Disaster Recovery Testing asks whether the business can be restored after a defined disaster, using recoverable data and the dependencies the service actually needs. A backup file or a healthy database by itself does not prove recovery.
Start from the recovery contract
Identify the primary and recovery regions, disaster scope, acceptable data loss, and the business restoration criteria from supplied contracts. Record exactly when RTO starts and what event counts as “recovered.” Keep missing RTO, RPO, or loss rules unknown instead of supplying a conventional target.
Build a dependency-ordered recovery path
Use the dependency map to connect the recovery data point to a usable business workflow.
| Recovery layer | Evidence to request |
|---|---|
| Data | Backup point, integrity evidence, decryption and restore result |
| Configuration and identity | Required settings, keys, permissions, and service identities |
| Network and routing | DNS, endpoints, routes, and access needed by the recovered region |
| Business service | Critical workflow, reconciled records, and user-visible readiness |
Backup existence proves neither decryptability nor a successful restore. An untested dependency, unavailable key, or unverified restore keeps the affected part of the recovery path unassessed.
Calculate RTO and RPO from evidence
Use timestamps from the supplied incident and recovery record. Measure RTO to the agreed business-ready event, not merely to process start or database health. Derive RPO from the disaster time and the actual recovered data point; preserve the underlying records and the calculation. If either timestamp or the objective definition is missing, report the calculation as unavailable.
Compare ledger entries, payment or order references, and required compensation with the accepted loss policy. Do not round away data outside the RPO or describe data integrity as proven by service health alone.
Illustrative calculation: assume sourced records place the disaster start at 10:00, the business restoration criterion is met at 10:45, and the latest recoverable data point is 09:55. The elapsed recovery time is 45 minutes, and the restored data point is 5 minutes before the disaster start. Compare both results with the approved RTO/RPO and data-loss rule. Without sourced objectives, start/end events, or timestamps, leave the result unassessed.
Place failover within the wider recovery plan
Failover may move traffic to a standby during a regional event. Disaster recovery also asks whether the chosen data point is usable and whether identity, configuration, network, dependencies, and business reconciliation are restored. A successful route switch is one possible recovery step, not proof of the full recovery objective.
Record a DRT-## finding
Capture the affected object or rule, disaster trigger and scope, objective source, expected concern, evidence state, impact and priority, owner role, close condition, and validation method. A recovery timeline should link failure time, selected backup or data point, restore stages, business readiness, and any integrity gap.
Keep validation bounded
Review supplied backup inventories, runbooks, dependency maps, and prior restore evidence as static material. Any restore drill should be a separately authorized, isolated candidate with a defined stop condition. Do not call production systems or report a restore as completed without a run record.
Related Skills
- Failover Testing: https://inaodeng.com/en/qaskills/failover-testing/ focuses on live primary/standby transitions.
- Recovery Testing: https://inaodeng.com/en/qaskills/recovery-testing/ covers recovery behavior after service or data loss.
Install and invoke
Install the Skill:
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en --skill disaster-recovery-testingInvoke disaster-recovery-testing with the approved recovery objectives, region and disaster scope, backup evidence, dependency map, and business restoration criteria:
Review these redacted disaster-recovery materials with disaster-recovery-testing.
Objectives and scope: [approved RTO/RPO, disaster start, primary/recovery regions, business-ready criterion]
Evidence: [backup/data point, dependency map, recovery timeline, data-integrity and business-reconciliation records]
State which objectives can be calculated and which remain unassessed. Provide candidate DRT-## findings and the smallest authorized restore-drill proposal. Do not treat a backup's existence or process startup as proof of business recovery.FAQ
Does an existing backup prove that disaster recovery will work? No. Verify backup integrity, decryption and restore, plus identity, configuration, network, dependencies, and business reconciliation.
Can I use a conventional target when RTO/RPO is undefined? No. Keep the objective and start/end events open for the owner; do not invent a threshold.
Source
Read the Disaster Recovery Testing prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/disaster-recovery-testing/prompts/disaster-recovery-testing.md. It defines the DRT-## contract and how to keep objective comparisons separate from unverified areas.