DisasterRecoveryOps

DisasterRecoveryOps is IT disaster recovery run as a continuous operational practice. For each service you agree two numbers with the business: how long it may be down (the recovery time objective, RTO) and how much recent data it may lose (the recovery point objective, RPO). You build a recovery capability that meets them, decide in advance who may declare a disaster and when, rehearse the failover and the return (failback), and measure what the rehearsals achieve.

AWS calls a disaster any event that “prevents a workload or system from fulfilling its business objectives in its primary deployed location”, whether natural, technical or human.^[1][2]

Having a DR plan is not the same as being able to recover. Four problems recur:

1. The clock runs before anyone acts. A one-hour RTO must cover detecting, notifying, escalating, assessing, declaring a disaster and recovering.^[3]
2. Nobody wants to press the button. Failover costs some availability and, with asynchronous replication, some data. If stakeholders decline to invoke while the RTO is at risk, AWS advises re-evaluating the plans.^[3]
3. The standby has drifted. Capacity, quotas, images and configuration in the recovery location age silently; “the only error recovery that works is the path you test frequently”.^[4]
4. Replication copies the damage. Deletions and corruption replicate too, so a highly available design can still lose data without a point-in-time copy.^[5]

• Not high availability. Availability “focuses on components of the workload, whereas disaster recovery focuses on discrete copies of the entire workload”.^[5]
• Not backup. Copies of data and tested restores belong to BackupOps; this page owns bringing the service back.
• Not business continuity. NIST separates the business continuity plan (keeping business processes going) from the disaster recovery plan, which “only addresses information system disruptions that require relocation”.^[6] AWS and Google describe DR as a subset of business continuity;^[7][8] the programme belongs to RiskOps.
• Not emergency management, where “disaster recovery” means community recovery (FEMA’s National Disaster Recovery Framework).^[9]
• Not a new discipline. No source found on 2026-10-16 uses “DisasterRecoveryOps”. “DROps” appears in one managed-service provider’s article as a framework that “coordinates people, processes, and technology for swift incident response”.^[10] The backup vendor Commvault promotes a neighbouring label, “Resilience Operations (ResOps)” (July 2026), measured by “Mean Time to Clean Recovery (MTCR)”.^[11] Both are vendor framing, not evidence of an established term.

NIST SP 800-34 Rev. 1 (2010) defines the vocabulary still in use: business impact analysis (BIA), RTO, RPO, maximum tolerable downtime (MTD) and alternate sites from cold to mirrored.^[6] Public cloud changed the economics more than the logic, since recovery can be scripted and rehearsed often, and regulation now demands tests, as the EU’s Digital Operational Resilience Act (DORA) has since 17 January 2025.^[16]

These are the Atlas-wide definitions. For RPO, NIST names a point in time and AWS the time back to it: the same objective.

Mental model: the recovery-time budget. People and systems share the RTO: detecting, escalating, assessing and declaring happen before any system moves, so a drill timed from the declaration measures only the second half. The figure uses the illustrative Lab 2 drill.

flowchart TB
  START(["T+0: impact, the 60-minute RTO clock starts"])
  subgraph people["People: 31 minutes"]
    direction LR
    D["Detect: 6 min"] --> X["`Escalate, assess,
    declare: 25 min`"]
  end
  subgraph systems["Systems: 33 minutes"]
    direction LR
    P["Prepare, fence: 2"] --> F["Fail over: 19"] --> V["Verify: 12"]
  end
  STOP(["T+64: service verified, RTO missed by 4"])
  START --> people
  people -->|"declared at T+31; deadline was T+22"| systems
  systems --> STOP
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class D,X risk
  class P,F,V core
  class START,STOP neutral

Recovery is split across Atlas pages. High availability reacts automatically and backup restores on request; disaster recovery starts with an invocation decision, which this page owns with the objectives and the orchestration.

1. Objectives come from the business and carry a price. NIST draws a cost-balance curve: shorter RTOs cost more.^[6]
2. The clock includes the decision. Name the invocation authority, write the activation criteria, and pre-authorise invocation when they are met.
3. Recover to a known-good point, not just the latest. If the fault is in the data or configuration, failover moves it too.
4. Prefer data-plane actions. AWS recommends “only data plane operations as part of your failover operation”.^[21] Make unavoidable control-plane calls, such as promoting a database, in the recovery Region, and rehearse them. Keep endpoints, credentials and runbooks outside the failure domain.
5. Few recovery paths, exercised often. Untested paths fail.^[4]
6. Failback is a second migration. Plan, rehearse and approve it like the failover.
7. Evidence or it did not happen. Every drill and invocation leaves a timed record.

NIST gives the ultimate authority to activate a plan to a senior management official, such as the CIO.^[6] The RACI below assumes that authority is delegated per service tier (R responsible, A accountable, C consulted, I informed).

The continuity manager is consulted on objectives and informed of every invocation. Communications follow IncidentOps, but Microsoft counts a communication plan as part of every DR plan;^[18] DR adds three messages: recovery invoked, which data may be missing and how it will be reconciled, and when failback will happen.

• Day 0, design. Run the BIA, assign tiers and objectives, map dependencies, choose a strategy per tier and record it in a register that tooling can check (Lab 1).
• Day 1, build and prove. Build the recovery environment as code, write the invocation policy and runbooks, and run the first planned switchover; a strategy that has never run is a hypothesis.
• Day 2, operate. Drill on a schedule, check drift after every change, review objectives yearly. Run real invocations through the three phases of NIST’s information system contingency plan (ISCP), applied here to DR: activation and notification, recovery, and reconstitution (validation, then deactivation of the plan).^[6]

• Invocation policy. One per service (reference implementation). NIST’s example ISCP activation criteria include damage extent, criticality and an expected outage longer than the RTO.^[6]
• Exercise cadence by impact. NIST suggests a tabletop for low-impact systems, a functional exercise with recovery from backup for moderate, and a full-scale exercise with failover to the alternate location for high-impact systems.^[6]
• Exercises that include people. Google’s disaster recovery testing (DiRT) runs real and fictitious incidents across the company to test technical systems, processes and people.^[22]
• Regulated sectors (check your jurisdiction). DORA requires EU financial entities under its full ICT risk framework to test continuity and response and recovery plans “at least yearly”, with switchovers to redundant capacity for entities other than microenterprises; Article 16 gives small and exempted entities a simplified framework.^[16] The US HIPAA Security Rule requires a disaster recovery plan (methods).^[23] These are examples, not legal advice.

A recovery location is only as complete as its weakest layer; check each for every tier-1 service.

Several stores, several recovery points. Orders in a database, documents in object storage, events in a queue: each store replicates with its own mechanism and lag (AWS lists S3 replication, Aurora global databases and DynamoDB global tables separately^[21]), so after failover an order may exist without its uploaded invoice. This Atlas’s rules: the effective RPO is the worst lag of any store the service needs, and lost writes are reconciled in every store. Mechanics belong to DBOps and StorageOps.

Recovery order across services. Bring services back in dependency order: identity, DNS, secrets and networking; data stores; the stateful middleware built on them; applications; traffic last. Site Recovery and VMware recovery plans sequence machines,^[26][27] and ARC Region switch runs ordered steps,^[28] but only your dependency map says what the order is. This Atlas’s rules of thumb for middleware and suppliers:

• Caches often start cold: size the database for the surge, or warm them before traffic moves.
• Queues and streams can lose or repeat in-flight messages: make consumers idempotent and let producers replay from the system of record.
• Search indexes and other derived stores can be rebuilt from the system of record; time the rebuild in a drill, because it can outlast the RTO.
• Suppliers and SaaS recover on their own terms: ask for their objectives and test evidence, and keep a manual workaround. DORA requires in-scope financial entities to keep tested exit plans for ICT services that support critical or important functions (Article 28).^[16]

Strategies run from cheap and slow to expensive and fast. AWS names backup and restore, pilot light, warm standby and multi-site active/active, with hot standby as a full-capacity variant;^[21] Google speaks of cold, warm and hot patterns,^[8] NIST of cold, warm, hot and mirrored sites.^[6]

For the loss of one data centre, AWS notes that a well-architected multi-AZ workload may need only backup and restore; Region-level strategies are for regional disasters or regulation.^[21]

flowchart TB
  U["Users"] --> R["`**Traffic control**
  DNS or global load balancer`"]
  K["`**Kept outside both Regions**
  runbook, endpoints, DR credentials`"] -.-> R
  R -->|"normal"| PA["`**Primary Region**
  app tier, full size`"]
  R -.->|"after invocation"| SA["`**Recovery Region**
  app tier, scaled down`"]
  PA --> PD["`**Primary data**
  database writer, object store`"]
  SA --> SD["`**Recovery data**
  a replica of each store;
  RPO = the worst store lag`"]
  PD -.-|"async, per store"| SD
  PD --> PB["`**Point-in-time backups**
  another account and Region`"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class PA,PD,SA,SD core
  class R,K decision
  class U,PB neutral

Happy path. The order matters: fence writes, promote the data tier, then move traffic.

%%{init: {"sequence": {"actorMargin": 24, "width": 120, "messageMargin": 30, "boxMargin": 6, "noteMargin": 6, "diagramMarginX": 8}}}%%
sequenceDiagram
  participant IC as Incident lead
  participant AU as Authority
  participant CO as DR lead
  participant PL as Platform
  IC->>AU: Impact, duration, readiness
  AU->>CO: Invoke DR (logged)
  CO->>PL: Fence the old primary
  CO->>PL: Promote the standby
  PL-->>CO: New writer confirmed
  CO->>PL: Shift traffic
  PL-->>CO: Traffic shifted
  CO->>AU: Smoke tests green
  AU->>IC: Announce, plan failback

Exception paths.

• The fault is in the data or configuration. Replication has copied it: restore a clean point in time or roll back.^[5]
• The standby is not ready. Quotas, capacity or drift block the failover: recover the most critical flows and escalate.^[4]
• The old primary may still accept writes. Fencing means making sure it cannot. If you can reach it, turn on the application’s write flag. If you cannot, no single control fences it: routing Off moves DNS traffic away,^[29] but not batch jobs, queue consumers, the old Region’s own application tier or clients with cached DNS. Have every client write through an endpoint that follows the new primary (Aurora’s global writer endpoint, Cloud SQL’s write endpoint^[30]), stop the old Region’s writers once it answers (scale them to zero or revoke their database credentials), and treat what they wrote meanwhile as lost writes. Aurora’s own fencing is best-effort; it warns that “Failovers are also susceptible to split-brain issues” and advises taking applications offline first.^[17]
• The access path shares the failure. In AWS’s October 2025 us-east-1 event, STS returned errors there, Identity Center instances configured there could not sign users in, and some console sign-ins failed in other Regions, while DynamoDB global tables kept serving elsewhere.^[25] Keep scripted access that avoids the failed Region.

Failback. After an unplanned failover, unreplicated writes are missing from the new primary until they are reconciled. Aurora then recommends a switchover “As a zero-data-loss method to fail back to the original primary Region after a failover”.^[17] Azure warns that failback “can be complex to plan and implement”.^[18]

stateDiagram-v2
  state "Running in recovery" as RIR
  state "Rebuilding primary" as RB
  state "Resynchronising" as RS
  state "Reconciling lost writes" as RC
  state "Ready to fail back" as RD
  state "Failing back (switchover)" as FB
  state "Normal operation" as N
  [*] --> RIR: failover complete
  RIR --> RS: primary back, old data saved
  RIR --> RB: primary site lost
  RB --> RS: rebuilt from code
  RS --> RC: replication caught up
  RC --> RD: data owners sign off
  RC --> N: keep recovery Region as primary
  RD --> FB: approved window
  FB --> N: RPO 0
  N --> [*]

This Atlas’s method, built on the database documentation:

1. Preserve first. Resynchronising overwrites the old primary: Aurora builds it a new storage volume after trying to snapshot the old one,^[17] and PostgreSQL’s pg_rewind leaves it “analogous to a base backup” of the new primary.^[31] Copy Aurora’s snapshot to a manual one: it expires with the old cluster’s backup retention period.^[17]
2. Diff a restored copy, never production, against the new primary by key and update time, for writes after the last replicated commit, in every store the service needs.
3. Classify. Rows only in the old copy are lost writes; rows changed on both sides are conflicts. Do not expect the database to merge them: Informix, for example, keeps lost transactions in a file but cannot reapply them, because conflicting updates may have happened on the new primary.^[32]
4. Replay through the application, idempotently, so business rules and downstream events run; data owners settle conflicts.
5. Record what was replayed, what was accepted as lost and who signed off (integrity).

Mandatory rules come only from regulation, contracts or a chosen certification; vendor frameworks are recommendations.

Start from the job, then the product. Examples span clouds, on-premises virtualisation and Kubernetes (checked October 2026).

Time-sensitive: ARC readiness check is closed to new customers; AWS recommends Region switch instead.^[40] Lock-in matters most for orchestration tools, which end up holding your runbooks.

Automate the execution; keep the decision human wherever a false alarm is expensive. AWS advises that automatically initiated failover “should be used with caution” and notes that “Manually initiated failover is therefore often used”, with the steps themselves automated.^[21] It lists console “click ops” and automatic recovery “in situations that present a high risk of data loss or unavailability” as anti-patterns, and asks for an abort mechanism.^[41] Full automation suits stateless and active/active services. An AI agent that runs failover steps needs the gates, logs, permissions and abort path of a script.

An illustrative tier-1 service, “checkout”, on AWS: an Aurora global database and ARC routing controls across two Regions; names, numbers and ARNs are placeholders. AWS is one representative platform: a Cloud SQL replica failover^[30] or a VMware recovery plan^[35] would keep the same policy, gates and drills. Four artefacts: a tier matrix (AWS suggests a similar one^[33]), an invocation policy, a gated failover script and its least-privilege role.

The decision deadline. This Atlas’s term for the latest point after impact at which an invocation can still meet the RTO: deadline = RTO − slowest prepare-execute-verify time among recent drills − safety margin. For checkout the slowest of the last three drills took 33 minutes (Lab 2); the 5-minute margin is a judgement that a real event runs slower than a drill (widen it while drills are few): 60 − 33 − 5 = 22 minutes. At the deadline, an outage of unknown length counts as “longer than the RTO”. Activation reuses the SLO burn-rate alert (SRE); lag comes from the secondary’s own metric, as the primary may not answer (Aurora: AuroraGlobalDBRPOLag).^[17]

Example status: YAML syntax-checked by the Atlas validator; illustrative values.

# Invocation policy for one service (illustrative values; adapt them)
service: checkout
tier: tier-1
# RPO: the worst lag of any store the service needs
objectives: {rto_minutes: 60, rpo_minutes: 5}
authority:
  # a role with deputies, never one named person
  accountable: head-of-platform-on-call
  deputies: [vp-engineering, cto]
  # the DR coordinator may invoke alone at the deadline if all invoke_when hold
  pre_authorised: true
# RTO 60 - slowest of the last three drills 33 - margin 5 (a judgement)
decision_deadline_minutes: 22
activation_criteria:    # any one starts an assessment
  - SLO burn-rate alert for checkout in the primary Region for 10 minutes
  - provider reports a regional event affecting a hard dependency
  - primary database writer unreachable from two zones
invoke_when:            # all must hold
  - outage expected to outlast the RTO, or its length unknown at the deadline
  - fault is not replicated (no corruption, bad deploy or stolen credentials)
  - recovery Region drift check green within 24 hours
  - >-
    lag below rpo_minutes on the secondary's own metric, for every store
    (unreadable = worst recent value), or the owner accepts more loss in writing
do_not_invoke_when:
  - the same fault is present in the recovery Region
fence:
  primary_reachable: application write flag on and confirmed before promotion
  primary_unreachable:  # routing Off alone steers only DNS traffic
    - every client writes through the global writer endpoint
    - old Region's routing control Off
    - its app tier, jobs and consumers scaled to zero as soon as it answers
    - writes accepted there meanwhile reconciled as lost writes
abort_when:
  - recovery smoke tests fail twice
  - the old primary is reachable, still accepts writes and cannot be fenced
failback:
  method: planned switchover after reconciliation across all stores
  approver: service-owner
  earliest: 24 hours of stable running in the recovery Region
evidence: drill and invocation logs kept for 3 years

The script moves one service in either direction, so failback needs no edits. It defaults to a dry run, uses endpoints and ARNs recorded in advance (AWS recommends a local copy of the ARC cluster endpoints^[42]) and stops at human gates. A switchover calls switchover-global-cluster in the current primary’s Region, as the Aurora guide shows and the API reference recommends;^[17][43] a failover calls failover-global-cluster --allow-data-loss in the target Region and reads the new writer from IsWriter.^[44][45]

Example status: syntax-checked with bash -n; dry runs executed on 2026-10-17, and the retry, escalation and gate paths exercised with a stub aws command; no AWS call was executed. To confirm in a game day: the RDS API in the recovery Region accepts the failover call while the primary Region is impaired.

#!/usr/bin/env bash
# Move one application's writer and traffic between its two Regions.
# Usage: region_failover.sh to-recovery|to-primary switchover|failover \
#          [--execute]
# Default: a dry run that prints the commands.
# Never add --safety-rules-to-override.
set -euo pipefail
DIRECTION="${1:-}"; MODE="${2:-}"; EXECUTE="${3:-}"
usage() {
  echo "usage: $0 to-recovery|to-primary switchover|failover [--execute]" >&2
  exit 2
}

# Recorded in advance for both directions: never look these up in a disaster.
ACCOUNT="111122223333"
GLOBAL_CLUSTER="orders-global"
CLUSTER_USE1="arn:aws:rds:us-east-1:${ACCOUNT}:cluster:orders-use1"
CLUSTER_USW2="arn:aws:rds:us-west-2:${ACCOUNT}:cluster:orders-usw2"
PANEL="arn:aws:route53-recovery-control::${ACCOUNT}:controlpanel/EXAMPLE"
RC_USE1="${PANEL}/routingcontrol/use1"
RC_USW2="${PANEL}/routingcontrol/usw2"
CLUSTER_ENDPOINTS=(  # "region url" pairs copied from DescribeCluster
  "us-west-2 https://host-aaaaaa.us-west-2.example.com/v1"
  "eu-west-1 https://host-bbbbbb.eu-west-1.example.com/v1"
  "ap-northeast-1 https://host-cccccc.ap-northeast-1.example.com/v1"
)
case "$DIRECTION" in
  to-recovery) FROM=us-east-1 TO=us-west-2 TARGET="$CLUSTER_USW2"
               RC_OFF="$RC_USE1" RC_ON="$RC_USW2" ;;
  to-primary)  FROM=us-west-2 TO=us-east-1 TARGET="$CLUSTER_USE1"
               RC_OFF="$RC_USW2" RC_ON="$RC_USE1" ;;
  *) usage ;;
esac
[[ "$MODE" == switchover || "$MODE" == failover ]] || usage

run() {
  if [[ "$EXECUTE" == "--execute" ]]; then "$@"
  else printf 'DRY RUN:'; printf ' %s' "$@"; printf '\n'; fi
}

confirm() {  # records intent; it does not enforce a second approver
  if [[ "$EXECUTE" != "--execute" ]]; then
    echo "GATE (skipped in dry run): $1"; return 0
  fi
  read -r -p "GATE: $1 Type yes to continue: " answer
  [[ "$answer" == "yes" ]] || { echo "aborted at gate" >&2; exit 3; }
}

# 1. Human gates: the authority's decision, then the fence that fits the case.
confirm "Invocation approved by the named authority and logged?"
confirm "Fenced? Write flag on, or if unreachable, clients on the global endpoint?"

# 2. Promote the standby. Switchover: call the current primary's Region, no data
#    loss. Failover: call the target Region; unreplicated writes are lost.
if [[ "$MODE" == switchover ]]; then
  run aws rds switchover-global-cluster --region "$FROM" \
    --global-cluster-identifier "$GLOBAL_CLUSTER" \
    --target-db-cluster-identifier "$TARGET"
else
  run aws rds failover-global-cluster --region "$TO" --allow-data-loss \
    --global-cluster-identifier "$GLOBAL_CLUSTER" \
    --target-db-cluster-identifier "$TARGET"
fi

if [[ "$EXECUTE" == "--execute" ]]; then
  writer=""
  for _ in $(seq 1 60); do  # wait up to 30 minutes for the new writer
    writer=$(aws rds describe-global-clusters --region "$TO" \
      --global-cluster-identifier "$GLOBAL_CLUSTER" --output text \
      --query 'GlobalClusters[0].GlobalClusterMembers[?IsWriter].DBClusterArn') \
      || writer=""  # an API error must not end the script before the escalation
    [[ "$writer" == "$TARGET" ]] && break
    sleep 30
  done
  if [[ "$writer" != "$TARGET" ]]; then
    echo "writer not promoted; escalate" >&2; exit 4
  fi
fi

# 3. Shift traffic with the ARC data plane, trying each cluster endpoint.
switched=false
for entry in "${CLUSTER_ENDPOINTS[@]}"; do
  region="${entry%% *}"; url="${entry#* }"
  if run aws route53-recovery-cluster update-routing-control-states \
      --region "$region" --endpoint-url "$url" \
      --update-routing-control-state-entries \
      "RoutingControlArn=$RC_OFF,RoutingControlState=Off" \
      "RoutingControlArn=$RC_ON,RoutingControlState=On"; then
    echo "routing change accepted via $region endpoint"; switched=true; break
  fi
  echo "endpoint in $region failed; trying the next one" >&2
done
if ! $switched; then
  echo "no cluster endpoint accepted the change; escalate" >&2; exit 5
fi

confirm "Write flag cleared in $TO and smoke tests green?"
echo "done: record timestamps in the drill log"

Who may run it, and with what. The script runs under an IAM role that can lose data and move production traffic, so the role allows only what the script calls, for one service: three RDS actions on its global database and two clusters, and the routing actions on its own control panel. ARC safety rules block unsafe routing changes, so the third statement denies overriding them, using the condition key AWS documents.^[46] Action names follow AWS’s service reference.^[47]

Example status: JSON syntax-checked; not attached to a real account.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "PromoteOnlyThisGlobalDatabase",
    "Effect": "Allow",
    "Action": ["rds:FailoverGlobalCluster", "rds:SwitchoverGlobalCluster",
               "rds:DescribeGlobalClusters"],
    "Resource": [
      "arn:aws:rds::111122223333:global-cluster:orders-global",
      "arn:aws:rds:us-east-1:111122223333:cluster:orders-use1",
      "arn:aws:rds:us-west-2:111122223333:cluster:orders-usw2"
    ]
  }, {
    "Sid": "SwitchOnlyThisControlPanel",
    "Effect": "Allow",
    "Action": ["route53-recovery-cluster:UpdateRoutingControlStates",
               "route53-recovery-cluster:GetRoutingControlState"],
    "Resource": [
      "arn:aws:route53-recovery-control::111122223333:controlpanel/EXAMPLE/*"
    ]
  }, {
    "Sid": "NeverOverrideSafetyRules",
    "Effect": "Deny",
    "Action": "route53-recovery-cluster:UpdateRoutingControlState*",
    "Resource": "*",
    "Condition": {
      "Bool": {"route53-recovery-cluster:AllowSafetyRulesOverrides": "true"}
    }
  }]
}

• Who assumes it. The DR coordinator and named deputies, through DR-only identities that can only assume this role, with MFA required, as ARC’s IAM guidance recommends.^[46] Overriding safety rules is a separate break-glass step.
• Where the credentials live. AWS’s ARC guidance: long-lived credentials used only for DR tasks, kept “in an on-premises physical safe or a virtual vault”, with everyday work on federated sign-in.^[48] Keep the vault outside the failure domain, alert on and rotate after every use (this Atlas’s practice), and test the path, token service included, from outside the primary Region.^[25]
• What the gates do. The confirm prompts record intent; anyone with the role can type “yes”. Enforce approval with two people (one opens the vault, another runs the script) or an ARC Region switch manual-approval block, which waits for someone with the approval role but does not run in ungraceful mode.^[38]

Labs 1 and 2 need only Python 3.8+. Lab 3 needs a non-production AWS environment and was not executed for this page.

Objective: find services that cannot meet their RTO with a safety margin, can lose more data than the RPO, depend on slower services, or have stale drills. Prerequisites: Python 3.8+, 30 minutes, no cloud account. Status: executed with Python 3.8.10, last on 2026-10-17; the output below is the actual output.

1. Save the portfolio as workloads.json and the checker as dr_plan_check.py.
2. Run python3 dr_plan_check.py workloads.json, then echo $?.
3. Fix identity: switch it to replication ("data": {"mechanism": "replication", "worst_lag_min": 1}), cut execute to 25 minutes and set last_drill to "2026-10-01". Then pre-authorise the decision: set decide to 15 for identity and checkout-api. Run again.

Example status: JSON and Python syntax-checked; executed.

{
  "as_of": "2026-10-16",
  "margin_min": 5,
  "max_days_since_drill": {"tier-1": 90, "tier-2": 180, "tier-3": 365},
  "workloads": [
    {"name": "checkout-api", "tier": "tier-1", "rto_min": 60, "rpo_min": 5,
     "steps_min": {"detect": 5, "decide": 20, "execute": 25, "verify": 10},
     "data": {"mechanism": "replication", "worst_lag_min": 2},
     "depends_on": ["payments-db", "identity"], "last_drill": "2026-08-20"},
    {"name": "payments-db", "tier": "tier-1", "rto_min": 30, "rpo_min": 1,
     "steps_min": {"detect": 3, "decide": 5, "execute": 5, "verify": 5},
     "data": {"mechanism": "replication", "worst_lag_min": 0.5},
     "depends_on": [], "last_drill": "2026-09-30"},
    {"name": "identity", "tier": "tier-1", "rto_min": 60, "rpo_min": 15,
     "steps_min": {"detect": 5, "decide": 20, "execute": 45, "verify": 10},
     "data": {"mechanism": "backup", "interval_min": 60, "copy_delay_min": 15},
     "depends_on": [], "last_drill": "2026-03-02"},
    {"name": "reporting", "tier": "tier-3", "rto_min": 1440, "rpo_min": 1440,
     "steps_min": {"detect": 30, "decide": 60, "execute": 480, "verify": 60},
     "data": {"mechanism": "backup", "interval_min": 1440, "copy_delay_min": 240},
     "depends_on": ["checkout-api"], "last_drill": null}
  ]
}

"""Check a DR portfolio: time budget, data-loss window, dependencies, drill age.
Usage: python3 dr_plan_check.py workloads.json   (exit 1 if any check fails)"""
import json
import sys
from datetime import date

DECIDE_WARN_SHARE = 0.25  # warn when deciding takes over a quarter of the RTO


def worst_loss(data):
    if data["mechanism"] == "replication":
        return data["worst_lag_min"]
    # backup: the interval plus the time to reach the copy you restore from
    return data["interval_min"] + data["copy_delay_min"]


def check(portfolio):
    as_of = date.fromisoformat(portfolio["as_of"])
    margin = portfolio["margin_min"]
    by_name = {w["name"]: w for w in portfolio["workloads"]}
    failures = 0
    for w in portfolio["workloads"]:
        problems, warnings = [], []
        estimate = sum(w["steps_min"].values())
        need = estimate + margin
        if need > w["rto_min"]:
            problems.append(
                f"needs {need} min with margin > RTO {w['rto_min']}")
        share = w["steps_min"]["decide"] / w["rto_min"]
        if share > DECIDE_WARN_SHARE:
            warnings.append(f"deciding uses {share:.0%} of the RTO")
        loss = worst_loss(w["data"])
        if loss > w["rpo_min"]:
            problems.append(
                f"worst-case data loss {loss:g} min > RPO {w['rpo_min']} min")
        for dep in w["depends_on"]:
            dep_need = sum(by_name[dep]["steps_min"].values()) + margin
            if dep_need > w["rto_min"]:
                problems.append(
                    f"dependency {dep} needs {dep_need} min > this RTO")
        limit = portfolio["max_days_since_drill"][w["tier"]]
        if w["last_drill"] is None:
            problems.append("never drilled")
        else:
            age = (as_of - date.fromisoformat(w["last_drill"])).days
            if age > limit:
                problems.append(f"last drill {age} days ago > {limit}")
        status = "FAIL" if problems else ("WARN" if warnings else "PASS")
        failures += bool(problems)
        head = f"{status:4}  {w['name']:<13} {w['tier']}"
        print(f"{head}  estimate {estimate} of {w['rto_min']} min")
        for p in problems + warnings:
            print(f"      - {p}")
    print(f"{failures} of {len(by_name)} workloads fail")
    return failures


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        sys.exit(1 if check(json.load(f)) else 0)

Expected output (step 2), exit code 1:

FAIL  checkout-api  tier-1  estimate 60 of 60 min
      - needs 65 min with margin > RTO 60
      - dependency identity needs 85 min > this RTO
      - deciding uses 33% of the RTO
PASS  payments-db   tier-1  estimate 18 of 30 min
FAIL  identity      tier-1  estimate 80 of 60 min
      - needs 85 min with margin > RTO 60
      - worst-case data loss 75 min > RPO 15 min
      - last drill 228 days ago > 90
      - deciding uses 33% of the RTO
FAIL  reporting     tier-3  estimate 630 of 1440 min
      - worst-case data loss 1680 min > RPO 1440 min
      - never drilled
3 of 4 workloads fail

Validation. After step 3 only reporting fails: it was never drilled, and a daily backup that takes four hours to reach its copy can lose 28 hours against a 24-hour RPO (the copy delay taught in BackupOps). An estimate equal to the RTO fails: it leaves no room for a slow day. Troubleshooting. KeyError: 'worst_lag_min' or 'copy_delay_min' means a data entry lacks a field; ValueError: Invalid isoformat string means a date is not YYYY-MM-DD. Teardown: delete the two files.

Objective: turn a drill’s timestamps into achieved RTO and RPO and see where the time went. Prerequisites: Python 3.8+, 20 minutes. Status: executed with Python 3.8.10, last on 2026-10-17. The drill log is illustrative.

1. Save drill-log.json and drill_report.py; run python3 drill_report.py drill-log.json.
2. Move declared to 09:22 and the three later events nine minutes earlier (09:24, 09:43, 09:55). Run again.

Example status: JSON and Python syntax-checked; executed.

{
  "workload": "checkout-api",
  "rto_min": 60,
  "rpo_min": 5,
  "events": {
    "disruption_start": "2026-10-14T09:00:00+00:00",
    "detected": "2026-10-14T09:06:00+00:00",
    "declared": "2026-10-14T09:31:00+00:00",
    "failover_started": "2026-10-14T09:33:00+00:00",
    "traffic_switched": "2026-10-14T09:52:00+00:00",
    "service_verified": "2026-10-14T10:04:00+00:00"
  },
  "last_replicated_commit": "2026-10-14T08:57:30+00:00",
  "deviations": [
    "DNS record TTL was 300 s, runbook assumed 60 s",
    "instance quota in the recovery Region too low; raised during the drill"
  ]
}

"""Score a DR drill from its event log: achieved RTO and RPO, and where the
time went. Usage: python3 drill_report.py drill-log.json
(exit 1 if the RTO or the RPO was missed)"""
import json
import sys
from datetime import datetime

PHASES = [("detect", "disruption_start", "detected"),
          ("decide", "detected", "declared"),
          ("prepare", "declared", "failover_started"),
          ("execute", "failover_started", "traffic_switched"),
          ("verify", "traffic_switched", "service_verified")]


def minutes(a, b):
    delta = datetime.fromisoformat(b) - datetime.fromisoformat(a)
    return delta.total_seconds() / 60


def report(log):
    ev = log["events"]
    rto = minutes(ev["disruption_start"], ev["service_verified"])
    rpo = minutes(log["last_replicated_commit"], ev["disruption_start"])
    print(f"Drill: {log['workload']}")
    for name, start, end in PHASES:
        m = minutes(ev[start], ev[end])
        print(f"  {name:<8}{m:5.1f} min  {m / rto:4.0%}")
    rto_ok, rpo_ok = rto <= log["rto_min"], rpo <= log["rpo_min"]
    margin = log["rto_min"] - rto
    print(f"Achieved RTO {rto:.1f} min vs target {log['rto_min']}: "
          f"{'MET' if rto_ok else 'MISSED'} (margin {margin:+.1f})")
    print(f"Achieved RPO {rpo:.1f} min vs target {log['rpo_min']}: "
          f"{'MET' if rpo_ok else 'MISSED'}")
    for d in log["deviations"]:
        print(f"  deviation: {d}")
    return rto_ok and rpo_ok


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        sys.exit(0 if report(json.load(f)) else 1)

Expected output (step 1), exit code 1:

Drill: checkout-api
  detect    6.0 min    9%
  decide   25.0 min   39%
  prepare   2.0 min    3%
  execute  19.0 min   30%
  verify   12.0 min   19%
Achieved RTO 64.0 min vs target 60: MISSED (margin -4.0)
Achieved RPO 2.5 min vs target 5: MET
  deviation: DNS record TTL was 300 s, runbook assumed 60 s
  deviation: instance quota in the recovery Region too low; raised during the drill

Validation. The phase shares add up to 100% (±1 for rounding). In step 2 the declaration meets the 22-minute decision deadline: achieved RTO becomes 55.0 minutes, margin +5.0, exit code 0. Troubleshooting. On Python 3.8–3.10, timestamps ending in Z raise ValueError; write +00:00. A negative phase means events are out of order. Teardown: none; keep the log as evidence.

Objective: prove in a non-production copy of a tier-1 service that the team can move the writer and traffic to the recovery Region and back without data loss, timing each phase. Prerequisites: an Aurora global database in two Regions, ARC routing controls on Route 53 records, a client writing one numbered row per second, AWS CLI v2 and the failover role. Cost and risk: hourly ARC and cross-Region replication charges (cost); use staging. Status: not executed.

1. Dry run. bash region_failover.sh to-recovery switchover prints the gates, then aws rds switchover-global-cluster --region us-east-1 ... and the routing update.
2. Execute. Run with --execute, answer the gates, and log the time of each event.
3. Fail back. Once both clusters report SynchronizationStatus connected,^[45] run region_failover.sh to-primary switchover --execute.
4. Score. Feed the timestamps to Lab 2.

Expected output. After step 2, describe-global-clusters shows the recovery-Region cluster with IsWriter true and get-routing-control-state returns On for its control. Validation. No acknowledged row is missing: a switchover synchronises before promoting.^[17] Troubleshooting. Switchover needs the same major and minor engine versions in both clusters;^[17] a safety rule can reject a routing update (ARC’s example allows only one replica on), so change both controls in one call;^[29] traffic still reaching the old Region usually means cached DNS. Teardown: confirm the original topology, stop the client, delete any ARC cluster created for the lab.

Three sourced events, three disaster shapes. The lessons are this Atlas’s analysis of what service recovery could do.

1. Site loss: the OVHcloud Strasbourg fire (2021). Problem: in March 2021 fire destroyed the SBG2 data centre and partly damaged SBG1. Context: some customers’ backups on the same site were lost; in 2023 a French commercial court ordered OVHcloud to pay damages to two of them, and OVHcloud said it would appeal.^[49] Where copies belong is a BackupOps lesson. Lesson here: could the service be rebuilt elsewhere within its RTO, with images, configuration, secrets, DNS and capacity outside the site? Success criterion: a drill that assumes the site, and the tooling hosted there, are gone.

2. One building, a regional outage: Google Cloud europe-west9 (2023). Problem: a water leak and fire forced one of the Region’s three buildings to power down. Context: Google’s internal regional Spanner database, which backs IAM and the Region’s control planes, lost quorum because, through a misconfiguration, it had “two of its three replicas in two different clusters in the building that was powered down”. Customers’ multi-zone Regional Persistent Disk volumes with a replica there turned read-only, and regional IAM stayed offline to resynchronise policies 13 hours out of date.^[50] Lesson: the provider’s regional control plane is a dependency zone redundancy cannot remove, so tier-1 services need a second Region and tooling outside the impaired one. Success criterion: a drill that removes a whole Region, control plane included.

3. A logical fault everywhere: the CrowdStrike update (2024). Problem: a faulty content update released at 04:09 UTC on 19 July 2024 and reverted at 05:27 UTC crashed Windows hosts with sensor 7.11 or later that received it;^[51] Microsoft estimated 8.5 million devices.^[52] Context: each device had to boot from recovery media or into safe mode, and the WinPE route could require its BitLocker recovery key.^[53] Lesson: a recovery site running the same software shares the fault, so failover does not help; the plan needs out-of-band access to recovery secrets and capacity for mass manual remediation (host recovery: SysOps).

Count recoveries, not documents: “services with a DR plan” is a vanity metric.

From the Lab 2 drill: achieved RTO = 10:04 − 09:00 = 64 minutes, margin −4. Decision latency = 09:31 − 09:06 = 25 minutes, against 22 − 6 = 16 allowed: a 9-minute overrun. Achieved RPO = 09:00:00 − 08:57:30 = 2.5 minutes. From Lab 1: two of three tier-1 services were drilled within 90 days (67% coverage); one of four passed every check (25% conformance). The fix is a faster decision, not a faster database.

• Security parity. The recovery location needs the primary’s guardrails, patching and logging. AWS recommends an account per Region for the strongest isolation and cross-account backup copies against insider threats or account compromise.^[21]
• Compromise and ransomware. Coordinate with ResponseOps before invoking; failing over into an environment the attacker can reach repeats the incident. DORA requires restores on own systems to use systems “physically and logically segregated from the source ICT system”.^[16]
• Integrity and records. DORA requires checks and reconciliations when recovering and readily accessible records of activities during disruptions;^[16] NIST’s reconstitution validates data and functionality before the plan is deactivated.^[6]
• Residency. Microsoft advises reflecting sovereignty and residency obligations in DR plans;^[18] the legal analysis belongs to PrivacyOps.

NIST frames the choice as balancing the cost of disruption against the cost of recovery, which rises as the RTO shrinks.^[6] Drivers are standby capacity, replication and data transfer (Aurora Global Database bills replicated write I/O to each secondary Region^[54]), licences, tooling and drill time. At October 2026 prices an ARC routing-control cluster costs $2.50 per hour, about $21,900 a year (2.50 × 24 × 365), and a Region switch plan $70 a month, $840 a year.^[55]

Capacity is the hidden cost. Quotas in the recovery Region must allow production scale,^[21] and scaling up during the disaster depends on control planes; pre-provisioned, statically stable capacity costs more but removes that dependency.^[21][20] Idle standby also consumes energy; pilot light and warm standby trade RTO for a smaller idle footprint (GreenOps covers measuring it).

Review the DR register monthly: coverage, conformance, open drift findings and overdue plan reviews. A rising decision latency means the policy or the authority is unclear. DORA requires independent internal audit reviews of response and recovery plans for in-scope financial entities other than microenterprises.^[16] Readiness tools help but do not replace drills; AWS points to Resilience Hub for tracking likely RTO and RPO.^[21]

1. T+0 to T+6, detect. SLO burn alerts fire for checkout; the provider reports an event affecting the database service. The incident commander opens the incident (IncidentOps).
2. T+6 to T+15, assess. The DR coordinator checks the invoke conditions: regional fault, not in the data; drift check green; secondary lag 40 seconds; recovery-Region quotas pre-raised.
3. T+15, recommend. To the authority: about 33 minutes to recover, up to 40 seconds of writes at risk.
4. T+22, decision deadline. Still no provider estimate, so the outage counts as outlasting the RTO; under the pre-authorisation the coordinator invokes and logs why.
5. T+22 to T+24, prepare. The degraded primary still answers, so the write flag fences it; the gates in region_failover.sh to-recovery failover --execute are confirmed.
6. T+24 to T+43, execute. The standby cluster is promoted; routing switches through the first reachable cluster endpoint.
7. T+43 to T+55, verify. Smoke tests and a cross-store consistency query (no order without its invoice) pass; the flag is cleared; recovery is announced.
8. Abort if smoke tests fail twice, or the old primary is reachable, still accepts writes and cannot be fenced: hold traffic in maintenance, escalate, never split writes.
9. After. Within 24 hours reconcile lost writes; schedule failback as a switchover; file the timeline.

• “We are multi-AZ, so we have DR.” Zone redundancy covers a data centre, not a Region or the provider’s regional control plane (europe-west9).^[50]
• “Fail over automatically on any failed health check.” Automate the steps, not the high-risk decision.^[41]
• “Never in production.” AWS lists never exercising failovers in production as an anti-pattern for DR testing.^[56]
• “Zero RTO and RPO for everything.” Unrealistic or over-strict objectives make recovery costly and complicated.^[33]
• “We will think about failback later.” Unrehearsed, the return risks data loss or strands the service.

Invest in invocation-grade DR when the BIA shows that losing a site or Region would cost more than standing recovery, when regulation or contracts set recovery objectives, or when many critical services depend on the workload.

Keep it light, or skip it, when the workload can be rebuilt from code and backups within its tolerance, when recovery would cost more than the loss, or when the business knowingly accepts a low-probability disaster; AWS treats both of the last two as legitimate.^[7] Alternatives: zone-level high availability, graceful degradation, a manual workaround, or transferring the risk, for example through insurance (RiskOps).

Hidden responsibilities come with every strategy above backup and restore: standby cost, drift control, drills, failback.

Strategy. Choose the cheapest strategy whose measured recovery, decision time included, meets the objectives. The bands are this Atlas’s starting heuristics, not a standard.

Invocation. The tree applies NIST’s activation criterion^[6] and AWS’s warning about replicated faults,^[5] plus two judgements of this Atlas: unknown at the deadline counts as outlasting the RTO, and an unready standby is worse than a degraded primary.

%%{init: {"flowchart": {"nodeSpacing": 22, "rankSpacing": 30}}}%%
flowchart TB
  A{{"`Impact beyond what
  HA absorbs?`"}} -->|"no"| N1["`Run it as an
  incident, not DR`"]
  A -->|"yes"| B{{"`Fault replicated
  to the standby?`"}}
  B -->|"no"| C{{"`Outage likely to
  outlast the RTO?`"}}
  B -->|"yes"| N2["`Do not fail over:
  restore a clean point
  in time or roll back`"]
  C -->|"no"| W["`Wait and degrade;
  log the decision`"]
  W -.->|"re-assess"| C
  C -->|"`yes, or unknown
  at the deadline`"| D{{"`Standby ready?
  Drift, capacity, access`"}}
  D -->|"yes"| F{{"`Replication lag
  within the RPO?`"}}
  D -->|"no"| E["`Escalate: partial
  recovery or rebuild`"]
  F -->|"yes"| I["`**Invoke: fail over**`"]
  F -->|"no"| G{{"`Owner accepts the extra
  loss in writing?`"}}
  G -->|"yes"| I
  G -->|"no"| W2["`Do not invoke yet:
  log, re-assess`"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class A,B,C,D,F,G decision
  class N2,E risk
  class I core
  class N1,W,W2 neutral

The Atlas’s proposed model, not an official one; each exit criterion is measurable.

Dependencies: infrastructure as code for the recovery location, a standby budget and the business owners’ time.

Preflight: before you rely on a strategy

• RTO, RPO and tier agreed by the service owner, compatible with every hard dependency
• Point-in-time copies in another account and location, for every store
• Recovery-location quotas and capacity cover production load
• Endpoints, credentials and runbooks outside the primary failure domain
• First planned switchover completed and timed

Invocation readiness and governance: monthly

• Drift check green for images, configuration and quotas; findings older than 30 days escalated
• Failover role and DR credentials tested from outside the primary; vault accesses explained
• Authority, deputies and contact routes current
• Decision deadline recalculated from recent drills

During failover

• Invocation logged with time, reason and approver
• Writes fenced before promotion (write flag; if unreachable, clients on the global writer endpoint, old writers stopped)
• New writer confirmed before traffic moves
• Smoke tests and a cross-store consistency query pass before reopening

Failback

• Primary resynchronised; lost writes reconciled and signed off by data owners
• Switchover window approved; customers informed if needed
• Post-failback drill report filed

One-page DR plan (per service)

Invocation decision record

Drill report: scenario; Lab 2 timeline; achieved RTO and RPO; decision latency against the deadline; deviations; actions with owners and dates; failback result.

BIA worksheet questions, adapted from AWS’s list:^[33] maximum downtime and data loss before unacceptable impact; kinds of impact; whether lost data can be recreated; dependants’ objectives; zone versus Region objectives; seasonal peaks; contractual penalties.

Is RTO the same as MTTR? No. RTO is a target agreed in advance; MTTR is an average over many incidents with known statistical caveats (IncidentOps).

How often should we test? Scale by impact, within any regulatory minimum (operating model); this Atlas suggests a quarterly timed drill per tier-1 service, plus tabletops for the decision.

We run on premises. Does any of this apply? Yes, unchanged; even split brain recurs. In VMware Live Site Recovery, if the protected site comes back after a disaster recovery, virtual machines run on both sites until you run the plan again to power off the old ones.^[35]

Do containers and Kubernetes change DR? The logic stays; the inventory changes. Rebuild cluster objects from code (GitOps) and recover volume data separately, after checking that it can reach the recovery Region (Velero’s AWS and Azure plugins do not migrate data between Regions^[37]). Running clusters belongs to KubernetesOps.

Our provider runs the infrastructure. Is DR their job? Partly: “DR isn’t an automatic feature of Azure”, says Microsoft; you map service capabilities to your own plan.^[18]

Does DR cover ransomware? Only with ResponseOps: containment and forensics first, then recovery to clean, segregated systems from a point before the compromise.^[16]

• Smaller blast radius first (established). Zonal shift and autoshift move traffic off an impaired zone;^[29] statically stable designs keep working without the control plane.^[20] Both make Region-level invocations rarer.
• Residency-bound and exit-ready DR (emerging). Microsoft describes cloud-to-site failover for a cloud exit, which Azure Site Recovery does not support natively.^[18]
• Continuous verification (growing). Fault injection that cuts cross-Region connectivity and pauses replication^[39] tests detection and invocation, not only mechanics.

Where to start by role. Beginners: In 30 seconds, the glossary and Lab 1. Engineers: the reference implementation, Labs 2 and 3 and the worked runbook. Architects: the building blocks and the decision framework. Leaders: when to use, cost, the maturity model and the judgement call.

• Decide: tiers and objectives with the business; one named invocation authority per service; a decision deadline.
• Build: the cheapest strategy whose measured recovery meets the objectives; point-in-time copies beside replication; a least-privilege failover role; access and runbooks outside the failure domain.
• Practise: timed drills by tier; tabletops for the decision; failback at least yearly for tier 1.
• Measure: achieved RTO and RPO, decision latency, coverage, conformance, failback proven.
• Watch for: replicated faults, drift, quotas, DNS caches, split brain.
• Next action: compute the decision deadline for your three most critical services.

Option A, wait: no data loss, no failback, no botched failover. Option B, invoke at T+22: meets the RTO if the drilled 33 minutes hold, at the cost of up to 40 seconds of writes to reconcile and a planned failback.

What the evidence says. “Root cause found” is not “service restored”. In AWS’s October 2025 us-east-1 event, the DNS problem was identified about 50 minutes after it began and DNS restored after 2 hours 37 minutes, but new EC2 launches were normal only after 14 hours 2 minutes, and the event ended after 14 hours 32 minutes.^[25]

Decision process. The question is whether your service is back before T+60, after dependent backlogs clear; a status page cannot tell you, and the policy written in calm conditions says to invoke at T+22 and log why. Waiting looks attractive because its costs stay hidden until T+60.

Where the answer changes. With a credible estimate well inside the RTO (mastery question 4), lag above the RPO, or a failover never rehearsed, waiting can be the better bet; record that reasoning too. Drill data, not the loudest voice, should set the deadline.

After this page you can explain RTO, RPO and the difference between HA, backup and DR; design a strategy per tier; write an invocation policy with a decision deadline; run and score a drill; and evaluate when not to fail over.

1. RTO 60 minutes; slowest recent drill 33 minutes from declaration to verified service; detection usually 6 minutes; margin 5 minutes. When is the decision deadline, and how long may deciding take?

2. A faulty schema migration corrupted order records ten minutes ago. The recovery-Region replica is healthy and 2 seconds behind. Do you fail over?

3. Why script failover with routing controls rather than edit weighted DNS records in the console?

4. Checkout (RTO 60, deadline T+22) is degraded. At T+15 the provider credibly estimates full recovery at T+40. Do you invoke at the deadline?

5. After an unplanned failover, finance reports about 30 seconds of orders missing. Where are they, and what do you do before failing back?

DisasterRecoveryOps is a new name for an old, sound discipline: agree what each service needs, build the cheapest recovery that meets it, and rehearse. The sources agree on the mechanics; their warnings are about what surrounds them: the decision nobody owns, the standby nobody checked, the access path that failed with the primary, the lost writes nobody reconciled.

A recovery capability is real only when someone may invoke it before the deadline, the path has run recently enough to trust, and the way back is as well understood as the way out. Prove all three with timestamps.

Product facts and prices are as of October 2026; claim-level evidence is in research/disasterrecoveryops-ledger.md.

Changelog. 2026-10-16: first edition (two of three labs executed). 2026-10-16, r1 (independent review): “outlast the RTO” criterion; least-privilege role; switchover call; fencing; multi-store RPO; DORA from EUR-Lex. 2026-10-17, r2 (score 88): on-premises, DRaaS, Google Cloud and Kubernetes tooling; recovery order; DR communications; role entry points; decision-tree loop. 2026-10-17, r3 (score 91): layered fencing for an unreachable primary; a method for reconciling lost writes; a compact decision tree; NIST origins wording; fewer restatements.