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 < 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.