Disaster Recovery Architecture Diagram: RPO, RTO and Four Strategies

High availability keeps a system running when a server or an availability zone fails. Disaster recovery is about the bigger failures: a whole region down, a corrupted database, a deleted account, ransomware. The plan for those has to exist before they happen, and the architecture decides how much data you lose and how long you are down.

This post defines the two numbers every DR design starts from, walks through the four standard strategies with their costs, and draws a warm standby setup across two regions.

RPO and RTO

• Recovery point objective (RPO): how much data you can afford to lose, measured in time. An RPO of 5 minutes means losing the last 5 minutes of writes is acceptable.
• Recovery time objective (RTO): how long the service can be down before it is back.

Both come from the business, not from engineering, and both cost money: every step toward zero data loss and zero downtime multiplies the infrastructure and the operational work. Ask what an hour of downtime costs and which data cannot be recreated, then pick the cheapest design that meets the numbers. Different parts of one system usually get different targets: checkout might need minutes, the reporting warehouse a day.

Four strategies

The AWS disaster recovery whitepaper groups DR into four strategies, ordered by cost and recovery speed. The same ideas apply on any cloud or in your own data centers.

Backup and restore rebuilds everything from backups and infrastructure code. It is enough for many internal systems, as long as the restore has been tested and the infrastructure can be recreated from code.

Pilot light keeps the data live (replicated databases, replicated buckets) but leaves the compute off or at zero. Recovery means starting and scaling the services.

Warm standby keeps a small but working copy running. It can serve traffic immediately at reduced capacity, and scales out during failover. Because it is always running, it is also easy to test.

Active/active serves users from both sites all the time. Failover is mostly a routing change, but writes in two regions bring conflict handling or a single-writer design, and the cost is two production environments.

Choosing for one system: an example

An online store taking 2,000 orders an hour asks for an RPO of 5 minutes and an RTO of 30 minutes for checkout. Backup and restore misses the RPO: nightly snapshots can lose a day of orders, and rebuilding the stack takes hours. Pilot light meets the RPO through database replication, but starting and warming the services, caches and search index in another region usually takes longer than 30 minutes the first time anyone tries. Warm standby meets both: the replica is seconds behind and the scaled-down services already run, so failover is promotion, scale-out and a DNS switch. Active/active would cut the RTO further but doubles the cost and adds write conflicts the store has no need to solve. The answer is warm standby for checkout and backup and restore for the reporting warehouse.

Backups are still needed

Replication copies mistakes too. If someone drops a table or ransomware encrypts data, the replica follows within seconds. Keep point-in-time backups that replication cannot touch:

• Snapshots and transaction logs retained for days or weeks.
• Copies in a separate account, with different credentials, so one compromised account cannot delete both.
• Immutable or locked backups where your platform offers them.
• Regular restore tests. A backup nobody has restored is a hope, not a backup.

The failover sequence

Write the steps down and keep them short:

1. Decide. Who can declare a disaster, and on what signal. Automatic failover for a whole region is risky; many teams automate detection and keep a human decision.
2. Promote the database replica in the standby region to primary.
3. Scale out compute in the standby region to full capacity.
4. Move traffic by switching DNS failover records or global load balancer weights. Account for DNS TTLs and clients that cache.
5. Verify with synthetic checks, then announce.
6. Plan the way back. Failing back is a second migration and needs the same care.

The architecture diagram

How to read it:

• Top: users reach DNS failover routing. Today it sends all traffic to the primary region; the dashed edge shows where traffic goes after failover.
• Left, the primary region: a load balancer, six app instances, object storage and the primary database.
• Right, the standby region: the same shape at smaller scale: two app instances, a replica database fed by asynchronous replication, and replicated objects. Dashed edges mark the paths that only carry traffic after failover.
• Bottom: daily snapshots go to a backup vault in another account, the protection against corruption and deletion that replication cannot provide.
• The Markdown block states the targets the design is meant to meet.

Testing

DR plans fail in the details: an expired certificate in the standby region, a hard-coded endpoint, a missing secret, a DNS TTL of one day. The only fix is to run the failover. Schedule drills, start with a single service, and measure the real RTO against the target. A warm standby makes this cheap, which is one of its biggest advantages over pilot light.

What to put on a DR diagram

• Both sites, with what runs in each and at what scale.
• Replication paths and their mode, synchronous or asynchronous, because that sets the RPO.
• The traffic switch, and whether it is automatic.
• Backups outside the blast radius, including the account boundary.
• The targets, written next to the design.

For the multi-region networking side, see the AWS multi-region architecture diagram. The database replication diagram explains replication lag and failover in more depth, and the incident response flowchart covers declaring and running the incident itself.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add two Region frames from the Cloud pack, one for the primary and one for the standby.
3. Inside each, add a Cloud LB, a Compute node for the app, an Object Storage node and a Managed DB. Put the instance counts in the labels.
4. Add a Person from the C4 Model pack and a DNS node from the Network pack above the regions, and another Object Storage node below for the backup vault.
5. Draw replication across the regions, dash the failover-only paths, and add a Markdown block from the Core pack with RPO and RTO.

The example uses 14 diagram nodes, within the Free plan.

FAQ

What is the difference between RPO and RTO? RPO is how much data you can lose, measured in time before the failure. RTO is how long it takes to be back in service after it.

Is high availability the same as disaster recovery? No. High availability handles component and zone failures automatically and continuously. Disaster recovery handles larger events such as a region outage or data corruption, often with a deliberate failover.

Do I still need backups if I replicate to another region? Yes. Replication copies deletions and corruption almost immediately. Backups in a separate account protect against those.

Which disaster recovery strategy should I choose? The cheapest one that meets the RPO and RTO the business needs for that system. Warm standby is a common middle ground because it is affordable and easy to test.

How often should I test disaster recovery? Regularly enough that the runbook stays true, often quarterly for critical systems, and after any major architecture change.

Start free — one seat, no credit card.