Backup, Replication, and Disaster Recovery Patterns

Goal

Teach the main disaster recovery patterns and show how backup, replication, and failover strategies fit different business expectations.

The Short Version

Disaster recovery is a ladder, not a binary choice. AWS commonly describes four broad strategies: backup and restore, pilot light, warm standby, and multi-site active-active. As you move up that ladder, recovery becomes faster, but cost, operating effort, and design complexity rise with it.

The durable idea is:

Disaster recovery is not one thing. It is a spectrum of patterns that trade speed for cost and complexity.

The Recovery Pattern Ladder

flowchart LR
    A["Backup and restore<br/><small>Lowest steady-state cost, longest recovery</small>"]
    B["Pilot light<br/><small>Core data and essential services always ready</small>"]
    C["Warm standby<br/><small>Scaled-down environment already running</small>"]
    D["Active-active<br/><small>Multiple active locations, fastest recovery</small>"]
    A --> B --> C --> D

Each step reduces recovery effort during an incident, but increases what you must keep running, replicating, testing, and paying for all the time.

Backup and restore focuses on restoring data and rebuilding infrastructure after the event. Pilot light keeps the critical data path and core services ready, while the rest is switched on during failover. Warm standby keeps a reduced but working environment alive in the recovery location. Active-active runs the service in multiple locations as a normal operating model rather than only during emergency recovery.

Practical Architecture Meaning

Backup and restore is not "bad" architecture. It is often the right answer for workloads that can accept slower recovery. It is especially reasonable for systems where the cost of downtime is moderate and the business can tolerate infrastructure rebuild and validation time.

Pilot light and warm standby become attractive when the business wants materially faster recovery but still cannot justify full always-on duplication. They also work well when the team can automate infrastructure creation and scale-out cleanly.

Active-active is the most demanding option. It can deliver very strong continuity, but it requires more than duplicated servers. It demands:

Careful traffic routing.
Clear data replication and write ownership rules.
Confidence that both sides stay in sync.
More mature observability and failover testing.

One of the most useful AWS reminders here is that replication alone is not the whole DR plan. The team also needs infrastructure as code, application deployment readiness, runbooks, validation steps, and regular tests. If backups exist but the restore process is unpracticed, the recovery design is incomplete.

Example: Three Workloads, Three DR Patterns

Consider three systems in the same company:

A back-office reporting tool can tolerate several hours of restoration. Backup and restore may be enough.
An internal ERP platform supports core operations all day. Warm standby may be a better fit because rebuilding everything during an incident would take too long.
A public digital channel drives revenue continuously. It may justify warm standby with aggressive replication, or even active-active if the outage cost is severe enough.

The lesson is not that every important system should move up the ladder. It is that each system needs a pattern that matches its recovery promise.

Trade-Offs

Decision	Benefit	Trade-Off
Backup and restore	Lowest steady-state cost	Slowest recovery and more operational steps during failover
Pilot light	Faster recovery with limited always-on resources	Requires disciplined automation and replicated core services
Warm standby	Better recovery speed and higher confidence	Ongoing cost for a live secondary environment
Active-active	Fastest recovery and strongest continuity posture	Highest complexity, highest cost, and hardest data coordination

Common Mistakes

Assuming snapshots alone equal disaster recovery. Data copies matter, but so do infrastructure rebuild, application startup, validation, and access control.
Choosing a pattern without testing failover. Untested recovery plans create false confidence.
Ignoring dependencies. A workload cannot recover cleanly if identity, networking, secrets, data stores, or external integrations are missing from the plan.

If Someone Asks You

If someone asks, "How would you explain the main AWS disaster recovery patterns to a business stakeholder?" a clear answer is:

AWS disaster recovery patterns form a ladder. Backup and restore is cheapest but slowest. Pilot light and warm standby reduce recovery time by keeping more of the platform ready. Active-active gives the fastest continuity, but it costs the most and takes the most operational discipline to run safely.

What You Should Remember

Disaster recovery design should be explicit about what is always running, what is restored later, and what kind of data loss and recovery time the business accepts.

The most important idea is this:

Replication helps recovery, but tested recovery is what makes the design believable.

Questions to Check Your Understanding

Why is backup and restore not the same as high availability?
What makes warm standby different from pilot light?
Why must DR patterns be tested instead of assumed?

Further Study

Disaster recovery options in the cloud - Use this for AWS explanations of backup and restore, pilot light, warm standby, and multi-site active-active.
REL13-BP01 Define recovery objectives for downtime and data loss - Use this for connecting DR pattern choice back to business-driven RTO and RPO targets.