Pick the cheapest disaster recovery pattern that meets your recovery time and recovery point targets for the disaster you actually expect. Backup and restore is slowest and cheapest. Pilot light and warm standby keep a copy running. Active/active is fastest and hardest. Most teams need a mix, tiered by system.
The four patterns in one pass
These names come from the AWS disaster recovery whitepaper, but the ideas apply anywhere.
Backup and restore: you keep backups, and after a disaster you rebuild infrastructure and load the data. Cheap to hold, slow to recover.
Pilot light: data is replicated to a second location and the core pieces, such as databases, are always on. The application servers exist as configuration but are switched off until needed.
Warm standby: a scaled-down but fully working copy runs all the time. It can take traffic at reduced capacity straight away, then scale up.
Multi-site active/active: the workload runs in more than one location and serves traffic from all of them. The whitepaper calls this the most complex and costly approach, with recovery time that can approach zero for most disasters.
How they differ in practice
| Pattern | Recovery speed | Ongoing cost | Main burden |
|---|---|---|---|
| Backup and restore | Hours or more | Lowest | Rebuild and restore under pressure |
| Pilot light | Faster | Low to moderate | Keep both locations deployed in step |
| Warm standby | Minutes to an hour | Moderate | Run and test a second environment |
| Active/active | Near zero for site loss | Highest | Data consistency across locations |
The pilot light and warm standby distinction trips people up. The AWS note puts it simply: pilot light cannot handle requests until you take extra steps, while warm standby can handle them immediately at lower capacity.
What none of them fix by themselves
Replication copies mistakes. If someone deletes a table, the deletion replicates. The whitepaper says this directly: continuous replication may not protect against corruption or malicious deletion as well as point-in-time backups do. Even with active/active, recovery from data corruption takes more than zero time and lands at a point before the damage was found.
So every pattern above still needs real backups, kept somewhere an attacker or a bad deploy cannot reach.
Choosing
Work through three questions.
- What is the disaster? Losing a server, a data centre, a whole region, an account, or a dataset? Each points to different designs.
- What are the RTO and RPO for this system? If you have not set them, start with our guide to RPO and RTO.
- Can you operate the result? A standby nobody tests is a liability. Warm standby helps here because it lets you test continuously.
Many teams end up with warm standby for the one or two systems that earn revenue and backup and restore for everything else. That is a sensible answer.
Whatever you pick, deploy from code
All the patterns depend on being able to recreate infrastructure quickly. The AWS guidance says to deploy with infrastructure as code, because without it restoring in a new location is complex and can blow past your RTO. Keep the code, configuration and machine images in the backup scope too.
Safeguard's asset discovery and SBOM scanning can help you list what a recovery environment must contain. There is a free scan at gold.safeguard.sh/scan.
Quick check
Is a read replica a disaster recovery plan?
Not by itself. It helps with site loss but copies bad writes. Pair it with point-in-time backups.
Do we need multiple regions?
Only if your disaster definition includes losing a whole region or a rule requires it. For losing one data centre, a well-built single region design may only need backup and restore.
Sources
Last reviewed: 19 October 2026.
