A disaster recovery plan is credible when the team can demonstrate restoration of a useful service.
A disaster recovery plan is credible when the team can demonstrate restoration of a useful service. RTO describes the target time to restore operation after disruption; RPO describes the tolerated data-loss window. Set both from business consequences, then test the complete application path rather than assuming that a backup file satisfies the targets.
Define the service you must restore
List the customer journeys, data stores, identity systems, DNS, certificates and external dependencies needed for a usable recovery. State what degraded operation is acceptable. Include how responders obtain credentials if the normal identity or documentation system is unavailable. Targets for a single database are incomplete if the rest of the application cannot reconnect.
Design a safe recovery exercise
Choose an isolated environment and representative protected data with appropriate access controls. Record the backup point, restoration start and each dependency milestone. Prevent restored workers from sending real emails, payments or provider calls unintentionally. Use a written scenario such as a lost database or unavailable region and make its assumptions explicit.
Measure loss and completion
Verify the restored data against known checkpoints and determine the newest recoverable operation. Measure elapsed time through application validation, not merely database import completion. Check permissions, scheduled work, integrations and important balances or counts. Record manual steps and unavailable dependencies; these explain why the observed recovery differs from the target.
Turn the exercise into maintenance
Assign repairs for missing credentials, slow transfer, undocumented ordering or failed validation. Repeat the affected path after fixing it and schedule future exercises when architecture or data volume changes. Keep backup retention, encryption and deletion policies aligned with business and data requirements. A successful exercise demonstrates the tested scenario at that time, not universal protection from every disaster.
- Related service
- A production runbook a small team can actually use
- On-call for startups without a dedicated SRE team
Frequently asked questions
What is the difference between RTO and RPO?
RTO concerns restoration time; RPO concerns the acceptable data-loss window.
Does a successful backup prove recovery?
No. Restoration, dependency recovery and application validation must also work.
Can we test with production data?
Use only an authorised, protected dataset and isolate outbound effects; synthetic or sanitised data may be more appropriate.
How often should we test?
Choose a cadence based on consequence and change, and repeat after material architecture or recovery-process changes.
What if the target is missed?
Record measured results and causes, then adjust the system or explicitly revisit the business target.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
A production runbook a small team can actually use
A runbook should help a responder move from a specific symptom to a safe decision.
On-call for startups without a dedicated SRE team
A small team can operate a useful on-call system if its promises match its staffing and tooling.
Incident severity levels: a practical escalation matrix
Incident severity should describe current or credible business impact, not how alarming a log message looks.