Backups, replication and disaster recovery are often grouped together, but they solve different problems. A resilient service normally needs a deliberate combination of all three.
1) Backup
A backup is a recoverable copy kept for restoration. It should preserve earlier points in time so that data can be recovered after deletion, corruption, ransomware, application error or other unwanted change.
A backup is useful only when it can be located, decrypted, restored and validated within the required time.
2) Replication
Replication keeps another copy current or nearly current. It improves availability and can support failover, but it may also copy corruption, deletion or malicious changes to the replica.
Replication reduces some hardware and site risks; it does not replace historical recovery points.
3) Disaster recovery
Disaster recovery is the broader capability to restore a service after a serious disruption. It includes people, procedures, access, infrastructure, data, communications, priorities and testing.
A disaster-recovery plan should identify the recovery location, required credentials, dependencies, sequence of restoration and decision authority.
4) What each protects
| Capability | Best suited to | Key limitation |
|---|---|---|
| Backup | Historical restoration | May take time to restore |
| Replication | Fast failover and availability | Can reproduce bad changes |
| Disaster recovery | Coordinated service restoration | Requires planning and testing |
5) RTO and RPO
The recovery time objective (RTO) is the target time to restore a service. The recovery point objective (RPO) is the maximum acceptable amount of recent data exposure measured in time.
These targets guide technology choices. A four-hour RTO and one-hour RPO require a different design from a two-day RTO and daily backup.
6) Recovery testing
- Restore representative data, not just a single file
- Confirm credentials and encryption keys are available
- Measure the actual recovery time
- Validate application integrity after restoration
- Record manual steps and external dependencies
- Test communication and decision roles
Operational review questions
Use these questions to connect the concept to a real service or environment:
- What failure scenarios is the design intended to tolerate?
- Which common-mode dependencies remain?
- How quickly is failure detected and who authorizes failover?
- Can the standby path carry full priority load?
- What did the most recent test reveal?
Related guides
What Failure Domains Mean in Digital Infrastructure
A plain-language explanation of failure domains, fault isolation, blast radius, and how infrastructure systems are designed to limit outages.
ResilienceRedundancy, High Availability and Fault Tolerance
A clear comparison of redundancy, high availability and fault tolerance, including failover, shared dependencies and common design mistakes.
Network & DeliveryAnycast Routing Explained — Why CDNs and DNS Work So Fast
A plain-language explanation of anycast routing and why it allows DNS providers, CDNs, and global platforms to deliver traffic from the nearest location.
Compute & StorageConsistency vs Availability Explained
A detailed, plain-language explanation of consistency vs availability in distributed systems, including trade-offs, real-world examples, and why systems cannot maximize both.