Deployment & Infrastructure View design intermediate

Disaster Recovery Topology

What is replicated where, in what order recovery happens, and the tested time each step takes.

flowchart TB
  subgraph pri["Primary site"]
    direction TB
    p1["Application tier"]
    p2[("Transactional DB")]
    p3[("Object storage")]
    p4["Secrets + config"]
  end
  subgraph dr["Recovery site — warm"]
    direction TB
    d1["Application tier<br/><i>scaled to 0 · IaC ready</i>"]
    d2[("DB replica<br/><i>async · lag &lt; 30s</i>")]
    d3[("Storage replica<br/><i>cross-region · 15 min</i>")]
    d4["Secrets replicated"]
  end

  p2 ==>|"async"| d2
  p3 ==>|"async"| d3
  p4 ==>|"sync"| d4

  subgraph run["Recovery sequence — tested 2026-05-18"]
    direction TB
    s1["1. Declare · 5 min"]
    s2["2. Promote replica · 8 min"]
    s3["3. Scale app tier · 6 min"]
    s4["4. Repoint DNS · 5 min<br/><i>TTL 60s</i>"]
    s5["5. Verify + reconcile · 12 min"]
    s1 --> s2 --> s3 --> s4 --> s5
  end
  dr --> run
  run --> res(["Restored — measured RTO 36 min"])

What it is

Not just what is replicated, but the ordered recovery procedure with measured timings. The sequence is the deliverable; the replication diagram alone is a statement of intent. The date of the last test is on the page because an untested recovery plan has an unknown RTO, not a stated one.

When you produce it

Alongside the RTO/RPO matrix, and updated after every test. In regulated sectors the test evidence is examinable, and "we have a plan" without a date is a finding.

Who reads it

Executives, who accepted the RTO. Operations, who run the steps under pressure. Regulators and auditors, who ask for the evidence.

What good looks like

  • Every step has a measured duration from a real test, not an estimate.
  • DNS TTL is stated. It is the most common reason a measured RTO overshoots.
  • Secrets, configuration and certificates are in the replication scope. They are the most commonly forgotten and they block everything.
  • The reconciliation step exists — after an RPO greater than zero there is data to reconcile, and somebody must own that.
  • Failback is planned too, not just failover.

Common mistakes

  • Replicating data but not the means to run it — no IaC, no images, no secrets in the recovery region.
  • A tabletop exercise recorded as a test. It is worth doing and it does not measure the RTO.
  • Ignoring dependencies outside the diagram: an identity provider, a licence server, a partner endpoint allow-listing only the primary egress address.
  • No failback plan, so the organisation runs in the recovery region for months.