What is disaster recovery?
A nightly backup tells you data exists somewhere. It says nothing about how many hours pass before anyone can use it again. Disaster recovery is the plan that answers that question, tested before the day it matters.
Disaster recovery
DR
Disaster recovery, or DR, is a rehearsed plan for restoring a system after a major failure. The failure could be a region outage, a vendor going down, or a database lost outright. The plan names who acts and in what order. It sets two targets: how much data can be lost, and how long recovery can take.
"We have backups" is the sentence that gets confused with disaster recovery. A backup is a copy of data sitting somewhere. The full plan covers more. It says which backup to restore, which server takes over, who gets paged, and how anyone confirms the restored system is actually correct.
The plan is built around two numbers. Recovery point objective (RPO) sets how much data the business can afford to lose, measured as time since the last good backup. Recovery time objective (RTO) sets how long the system can stay down before the cost is too high. A plan with no stated RPO and RTO is a good intention, not a target anyone can be held to.
Why backups alone are not a plan
A backup that has never been restored is a guess. Storage can be corrupted. A restore script can be years out of date. A backup can be missing a piece the application needs, like environment secrets or a search index. None of that shows up until someone tries to bring the system back and it does not work.
- 01A backup answers: does a copy of the data exist?
- 02A DR plan answers: who restores it, in what order, and how fast?
- 03A tested DR plan answers: does the restore actually work, on a schedule someone checked?
- TriggerThe condition that declares a disaster, not a normal incident.
- OwnerOne named person decides and directs the response.
- Failover targetWhere the system comes back up: another region, another provider.
- Restore procedureThe exact steps, written down before the day it is needed.
- VerificationProof the restored system is correct, beyond simply running.
- CommunicationWho tells customers and when, agreed in advance.
Most plans stop at the restore procedure. The step that gets skipped most often is verification: a system that comes back up with silently corrupted data is worse than one that stays down.
Common questions
01What is the difference between disaster recovery and a backup?
A backup is a copy of data. Disaster recovery is the full plan for restoring service after a major failure. It covers who acts, what order they follow, and how fast and how completely the system comes back. A backup is one input to that plan, not the plan itself.
02What is the difference between disaster recovery and a rollback?
A rollback returns a system to its last known-good release, usually in minutes, after a bad deploy. Disaster recovery covers a larger event: a lost region, a failed vendor, or a database that is gone outright. Rollback fixes the last change. DR restores the whole system.
03How often should a disaster recovery plan be tested?
At minimum, whenever the system changes enough to affect the restore path: a new database, a new region, a new critical dependency. Many teams run a scheduled drill on a fixed calendar, commonly quarterly, so the test cadence does not depend on someone remembering.
04Does every system need a disaster recovery plan?
Every system that the business depends on needs one, sized to what an outage actually costs. An internal reporting tool can tolerate a slower, simpler plan than a payment system. The plan should match the cost of downtime, not a fixed template applied everywhere.
Related terms
- Rollback →Returns a system to its last known-good version in minutes, for a bad release rather than a lost region or vendor.
- SLA (service-level agreement) →Where a recovery target becomes a written promise with a stated consequence for missing it.
- Software maintenance →Where disaster recovery plans get drilled, timed and kept current on a live system.
