Disaster recovery (DR) is the planned set of policies, tools and procedures for restoring IT systems, data and services after an event that makes the primary environment unusable, such as a site fire, a large hardware failure, a ransomware attack or a regional cloud outage. In backup and recovery it is the discipline that turns backups into working services again within agreed time limits.
A disaster recovery plan documents who does what, in which order and with which resources. DR is a part of the broader business continuity effort, which also covers people, facilities and manual workarounds, while DR focuses on servers, storage, networks and applications.
Recovery objectives that define disaster recovery
Every DR design starts with two business-driven targets. The recovery time objective (RTO) is the maximum acceptable time from the disaster until the service runs again. The recovery point objective (RPO) is the maximum acceptable amount of data loss, expressed as time before the incident.
Both values come from a business impact analysis, not from technology. A payment system may require an RTO of minutes and an RPO near zero, while an internal wiki may tolerate a day for both. The table below summarizes the key metrics.
| Metric | Question it answers | Typical range |
|---|---|---|
| RTO | How long may the service be down | Minutes for critical systems to days for minor ones |
| RPO | How much recent data may be lost | Near zero to 24 hours or more |
| Maximum tolerable downtime | When does the outage threaten the business | Set by management, longer than RTO |
| Recovery time actual | How long recovery really took in a test | Measured during restoration tests |
Tighter objectives cost more. Moving from an RPO of 24 hours to near zero usually means replacing nightly backups with continuous replication, and moving from an RTO of days to minutes means keeping standby infrastructure running at all times.
Disaster recovery site strategies
DR strategies are classified by how ready the recovery environment is before the disaster. Readiness determines both achievable RTO and ongoing cost.
| Strategy | State before disaster | Typical RTO | Relative cost |
|---|---|---|---|
| Backup and restore | Only offsite or cloud backups exist | Hours to days | Lowest |
| Cold site | Space and power, little or no hardware | Days | Low |
| Pilot light | Core data replicated, minimal services running | Hours | Moderate |
| Warm standby | Scaled-down copy of production running | Minutes to hours | High |
| Hot site or active-active | Full capacity running and synchronized | Seconds to minutes | Highest |
Cloud platforms have made pilot light and warm standby affordable for smaller organizations, because compute capacity can be started on demand while only storage and replication run continuously. Disaster recovery as a service offerings package this model with orchestration tools.
Disaster recovery compared with related practices
Disaster recovery is often confused with backup or high availability. Each addresses a different failure scope, and a robust environment combines them.
| Practice | Protects against | Does not protect against |
|---|---|---|
| Backup | Data loss, deletion, corruption | Long downtime by itself |
| High availability | Single component failures within a site | Site loss, logical corruption replicated instantly |
| Disaster recovery | Loss of a whole site or environment | Minor faults that HA handles faster |
| Business continuity | Disruption to the whole organization | Nothing technical by itself, it coordinates |
A key insight is that replication is not backup. If ransomware encrypts production data or an administrator deletes a database, synchronous replication copies the damage to the DR site within seconds. Effective DR plans therefore combine replication with immutable or air-gapped backups and point-in-time recovery, often following the 3-2-1 backup rule.
Building and testing a disaster recovery plan
A usable DR plan is a runbook, not a policy statement. It must be specific enough that a competent engineer who did not write it can execute it under pressure.
- Inventory and classify systems by criticality, and record their dependencies such as DNS, identity services and databases.
- Assign RTO and RPO to each tier based on the business impact analysis.
- Choose a strategy per tier, from backup and restore for low tiers to warm standby or active-active for critical ones.
- Document recovery order, because applications fail if they start before the directory, database or network they depend on.
- Define roles and communication, including who declares a disaster and how staff reach each other if email is down.
- Test regularly and update the plan after every test and every major infrastructure change.
Tests range in depth. The table below shows common test types and what each one proves.
| Test type | What happens | What it proves |
|---|---|---|
| Tabletop exercise | Team walks through a scenario on paper | Roles and decisions are clear |
| Restoration test | Selected systems restored in isolation | Backups are usable and complete |
| Partial failover | Some services run from the DR site | Replication and runbooks work |
| Full failover | Production moved to the DR site | Actual RTO and RPO are achievable |
Common failure points in disaster recovery
Most DR failures come from assumptions that were never tested. Recurring problems include backups that cannot be restored because encryption keys were stored only in the lost site, and DR environments that drifted from production after months of unreplicated changes.
- Forgotten dependencies such as licensing servers, certificates or DNS records hosted only at the primary site.
- Credential lockout when identity systems or password vaults are unreachable during the disaster.
- Shared fate, where the DR site uses the same power grid, provider region or administrative accounts as production.
- Undersized capacity at the DR site, which runs but cannot handle normal load.
- No failback plan, leaving services stranded at the DR site after the primary is repaired.
Ransomware has changed DR planning significantly. Recovery must assume that attackers may have compromised backup consoles and administrator accounts, so isolated credentials and verified clean restore points are as important as raw restore speed.
The short version
Disaster recovery is an organization’s prepared plan for getting its computer systems working again after something serious goes wrong. Examples include a fire in the server room, a flood or a cyberattack that locks every file.
The plan sets how quickly each system must return and how much recent data may be lost. It also says who does what. Like a fire drill, it only works reliably if people practice it regularly.
Where it makes a difference
A logistics company runs its order management system in one data center. Its plan sets an RTO of four hours and an RPO of fifteen minutes for this system. Database changes are replicated every few minutes to a warm standby in a cloud region, and nightly immutable backups are kept for thirty days.
When a cooling failure forces the primary data center offline, the on-call team follows the runbook. They promote the standby database, start the application servers and switch DNS. Orders are flowing again in about two and a half hours, with roughly ten minutes of data to re-enter. The quarterly failover tests had already revealed a missing certificate, which was fixed long before the real event.