A vendor-neutral resilience and disaster recovery cheat sheet for RTO, RPO, high availability, backup, replication, standby patterns, failover, and testing.
Use this page for rapid architecture review after reading the full Resilience and Disaster Recovery guide. The objective is not to memorize product names. It is to identify the failure scenario, business tolerance, state-protection need, and operating evidence that determine a defensible design.
| Concept | Primary question | Does not prove |
|---|---|---|
| Availability | Can users successfully use the service now? | That data can be restored after corruption |
| Reliability | Does the service behave correctly over time? | That every large disaster is covered |
| Durability | Will committed data remain intact? | That the application remains online |
| Recoverability | Can the required service and data be restored? | That recovery is fast enough |
| High availability (HA) | Can service continue through expected local failures? | Regional or cyber-disaster recovery |
| Disaster recovery (DR) | Can acceptable service be restored after a major disruption? | Continuous service during normal failures |
| Fault tolerance | Can the system continue through a defined failure with little interruption? | Protection outside that defined failure scope |
| Resilience | Can the system absorb, adapt to, and recover from disruption? | That any single feature makes the whole system resilient |
Starting with a vendor feature reverses the design process. Start with the outcome and failure instead.
| Objective | Meaning | Design pressure |
|---|---|---|
| RTO | Maximum acceptable time until the required service is restored | Detection, decisions, automation, standby capacity, routing, validation |
| RPO | Maximum acceptable interval of data loss in the recovered state | Backup frequency, replication lag, transaction capture, reconciliation |
| MTD or MTPD | Longest disruption the business can tolerate before impact becomes unacceptable | Outer business limit for technical and business recovery |
| WRT | Time after technical restoration to validate data and resume business work | Reconciliation, integrity checks, process restart |
| MTTR | Observed average time to restore or repair | Operational evidence; not a guarantee for each event |
| Availability SLO | Target successful service over a measurement window | Normal reliability and error-budget decisions |
RPO looks backward from the incident to the latest acceptable recoverable state. RTO looks forward from the disruption to validated service restoration.
| Mechanism | Best at | Weak when used alone |
|---|---|---|
| Local redundancy | Component, host, rack, or zone failures | Larger shared failures and corruption |
| High availability | Continuing service through expected failures | Historical recovery and severe disasters |
| Replication | Maintaining another usable copy with low lag | Deletion, corruption, or malicious changes that replicate |
| Backup | Recovering an earlier point in time | Immediate continuity and low RTO |
| Disaster recovery | Restoring service after a defined large disruption | Preventing every interruption |
| Immutable or isolated recovery copy | Reversing destructive or unauthorized changes | Fast service restoration unless the recovery path is prepared |
Backup and replication are complementary. Replication can reduce recovery time and data loss for infrastructure failures. Versioned, immutable, and administratively isolated backups provide a path back before logical damage occurred.
| Failure scope | Typical protection pattern | Hidden shared dependency to check |
|---|---|---|
| Process or instance | Restart, replacement, health checks, stateless design | Shared storage or configuration |
| Rack or local facility | Redundant power, network, and placement | Common switches, power, or control plane |
| Zone or data center | Multi-zone service and data placement | Single-zone egress, appliance, or state tier |
| Region or site | Cross-region or cross-site recovery | Identity, DNS, keys, artifact registry, decision authority |
| Provider or platform | Portable data, alternate operating path, exit plan where justified | Common identity, domain registrar, or software supply chain |
| Logical corruption or deletion | Versioning, point-in-time recovery, protected backups | Replication carrying damage forward |
| Ransomware or privileged compromise | Immutable copies, administrative isolation, clean-room recovery | Compromised keys, backup control plane, or recovery credentials |
Redundant components that depend on the same fragile control plane are not independent. Draw dependencies, not only regions and zones.
| Pattern | Normal state | Relative cost | Typical recovery profile | Main risk |
|---|---|---|---|---|
| Backup and restore | Recovery environment absent or minimal | Lowest | Slowest RTO; RPO depends on recoverable copies | Rebuild and restore take longer than assumed |
| Pilot light | Core stateful services or minimal foundation active | Low to medium | Faster than full rebuild | Scale-up path, quotas, and configuration drift |
| Warm standby | Smaller complete environment running | Medium to high | Faster RTO with continuous replication | Standby capacity or dependencies not ready |
| Hot standby | Full or near-full secondary environment ready | High | Rapid failover | Cost and operational drift |
| Active-active | Multiple locations serve production traffic | Highest | Potentially smallest interruption | Data conflicts, split brain, routing, and operational complexity |
| Cyber recovery | Isolated copies and clean recovery environment | Varies | Optimized for trusted restoration, not only speed | Restoring compromised data or credentials |
Choose the least complex pattern that demonstrably meets the target. Near-zero objectives have significant consistency, cost, and operational consequences.
| Topology | Use when | Verify before choosing |
|---|---|---|
| Active-passive | Simpler write ownership and failover are acceptable | Promotion, fencing, capacity, traffic switch, stale clients |
| Active-active reads | Read scale or local latency matters; writes can remain centralized | Replica lag and read-after-write expectations |
| Active-active partitioned writes | Ownership can be divided by tenant, key, or geography | Rebalancing, ownership changes, hot partitions |
| Active-active shared writes | The data model supports multi-writer conflict handling | Consistency, conflict resolution, duplicate operations, split brain |
Fencing is mandatory when two nodes might believe they are primary. Detecting failure is not enough; the old writer must be prevented from continuing before the replacement safely accepts writes.
| Choice | Benefit | Cost or risk |
|---|---|---|
| Synchronous replication | Tight data-loss objective within the protected scope | Write latency and reduced availability during partitions |
| Asynchronous replication | Lower latency and longer-distance practicality | Replication lag and possible acknowledged-write loss |
| Single-writer topology | Simpler ordering and conflict control | Promotion and writer-location dependency |
| Multi-writer topology | Local writes and broader active service | Conflicts, convergence, and application complexity |
| Strong consistency | Current agreed value before success | Coordination latency and partition trade-offs |
| Eventual consistency | Availability and geographic scale | Stale reads and explicit conflict semantics |
Do not infer an RPO of zero from the word replicated. Ask whether replication is synchronous, which writes are acknowledged, what happens during a partition, and how promotion handles queued or divergent changes.
Automatic failover is appropriate only when health signals are trustworthy and false positives are less dangerous than delayed recovery. Otherwise, automation should prepare and validate while an authorized operator makes the final decision.
| Evidence | Question it answers |
|---|---|
| Restore completion and integrity checks | Can protected data actually be recovered? |
| Measured end-to-end recovery time | Did the service meet RTO, not merely infrastructure startup time? |
| Recovered point or measured data loss | Did the result meet RPO? |
| Critical-flow tests | Can users complete the required business operations? |
| Identity, keys, DNS, and integration checks | Did hidden dependencies survive? |
| Capacity and load results | Can the recovery environment handle real demand? |
| Decision and communication record | Were roles and authority usable under pressure? |
| Failback or permanent-migration plan | Can the organization leave the recovery state safely? |
Use multiple exercise types: document review, tabletop, component restore, partial failover, and full service exercise. A successful tabletop does not prove that data can be restored; a successful database restore does not prove that the business service can resume.
| Trap | Corrective rule |
|---|---|
| “Multi-zone means disaster recovery” | Multi-zone HA and cross-region recovery protect different failure scopes. |
| “Replication replaces backup” | Replication can copy corruption and deletion; retain recoverable historical states. |
| “Durable storage means the application is available” | Durability protects data; availability requires a functioning service path. |
| “The standby exists, so RTO is met” | Measure detection, authorization, activation, routing, and validation end to end. |
| “RPO equals backup interval” | Effective RPO depends on successful, consistent, accessible, restorable copies. |
| “Active-active is always best” | It adds conflict, consistency, routing, and operating complexity. |
| “Failback is just reversing failover” | Data divergence and renewed risk make failback a separate controlled migration. |
| “A plan is evidence” | Only exercised recovery with measured results demonstrates capability. |
Primary background references: NIST SP 800-34 Rev. 1, the Google Cloud disaster recovery planning guide, the Google SRE book, Azure reliability guidance, and AWS disaster recovery patterns.