Disaster recovery
Set recovery priorities before everything feels urgent.
A recovery plan translates business impact into a realistic order of work, with explicit objectives for service restoration and data loss.
Separate the two recovery questions
Recovery time objective, or RTO, describes the target time for restoring a service after disruption. Recovery point objective, or RPO, describes the acceptable data-loss window measured in time. They answer different questions. A fast restore can still recover data that is too old.
Agree these objectives with business owners using the consequences of downtime and lost transactions. Do not copy the same target onto every system. A critical ordering service and an internal archive may justify different recovery designs, costs and testing frequencies. An objective is a planning target, not proof of capability or a service guarantee.
Plan dependencies, not just servers
An application may need identity, network access, DNS, certificates, database services and external integrations before users can work. Restoring its virtual machine is only one part of the sequence. Record these dependencies and identify which people or providers can restore them.
Include access to recovery credentials and instructions when normal systems are unavailable. A plan stored only on the failed platform is difficult to use. Protect alternative access carefully, and test it without weakening everyday security controls.
Compare objectives with evidence
Measure the complete recovery path, including decision time, access, restoration and business validation. If a test misses the objective, record the gap and choose whether to improve the capability, change the dependency design or formally revise the target. An optimistic document does not make an untested recovery process faster.
In practice
The restore finishes, but the target is still missed
Illustrative scenario, not a client case study.
In a hypothetical wholesaler, the ordering service has an agreed four-hour RTO and one-hour RPO. These are illustrative business targets, not a Threvol service commitment. A recovery exercise finds that the newest usable copy is ninety minutes older than the disruption.
- The team records that the available recovery point misses the one-hour data-loss target by thirty minutes, even if the restore itself succeeds.
- The database restore takes three hours, but identity recovery and business validation extend the full outage to five hours. The test therefore also misses the four-hour restoration target.
- The owners review backup frequency, usable-copy reliability and dependency sequencing. They agree corrective actions and a follow-up exercise instead of reporting the database restore alone as success.
Recovery objectives apply to the usable business service and the available data, not just the fastest technical step. Testing makes the gap between the plan and the capability visible.
What to put in place
- Agree service-specific restoration and data-loss objectives.
- Map identity, network, application and supplier dependencies.
- Provide protected access to recovery instructions and credentials.
- Measure the full recovery path and track gaps against the objectives.
The takeaway
A useful recovery plan makes tradeoffs explicit before an incident. It tells the team what matters first and provides a way to prove whether the plan is realistic.