Disaster recovery
DR site selection
A disaster recovery site has to be far enough away to not share a disaster, and close enough for the replication mode you need. Those two constraints — plus what facilities actually exist in the candidate market — decide the shortlist before any vendor conversation. The tool below runs all three against real data: measured round-trip times between 14 markets, and the 1629-facility catalog.
DR pair finder
Pick your primary market. Candidates are ranked by round-trip time, with the replication mode each distance supports.
| DR candidate | RTT | Replication supported | Facilities in market |
|---|
RTT figures are published cloud inter-region measurements (Azure, cloudping.co) — sources on the latency matrix. Fibre routes between colocation facilities follow similar paths; verify the exact pair with the operators before committing an RPO to it.
Replication mode is set by physics
Light in fibre covers roughly 100 km per millisecond of round trip. That single number decides the architecture: synchronous replication needs the round trip inside the application's write budget, which caps the distance near 100 km — and everything farther is asynchronous, whatever the storage layer promises.
| Mode | RTT budget | RPO | What it means |
|---|---|---|---|
| Synchronous | ≤ ~10 ms | Zero | Every write is confirmed at both sites before the application proceeds. Transaction latency includes the round trip, so distance becomes an application tax. |
| Near-synchronous | ~10–25 ms | Seconds | Writes stream continuously with acknowledgement relaxed. The practical choice for metro-adjacent pairs like Frankfurt–Amsterdam or Singapore–Kuala Lumpur. |
| Asynchronous | Any | Minutes | The DR site lags by the replication interval. The only option across long distances — and the right one for most workloads anyway. |
Four DR patterns, priced honestly
Cost is expressed as a share of the primary site's run cost. The pattern decides RTO; the replication mode decides RPO; and the combination decides the budget. Most estates run different patterns for different tiers of workload — active-active for the revenue path, backup-restore for everything that can wait a day.
| Pattern | RPO | RTO | Cost vs primary | How it works |
|---|---|---|---|---|
| Backup and restore | Hours–day | Days | ~5% | Backups replicated off-site, infrastructure built only when disaster strikes. Cheap, slow, and the restore is the part nobody has tested. |
| Pilot light | Minutes–hours | Hours | ~10–20% | Core data replicated to a minimal footprint that scales up on failover. A few racks at the DR site carrying the databases; compute arrives when needed. |
| Warm standby | Seconds–minutes | Minutes–hour | ~30–50% | A scaled-down copy of production running continuously. Failover is a promotion, not a build. |
| Active-active | ≈ Zero | ≈ Zero | 100%+ | Both sites serve traffic; losing one is a capacity event, not an outage. Requires the application to be built for it — retrofitting is a rewrite. |
Model the standby footprint's cost with the colocation cost estimator at the target market's Index rate.
What actually fails
DR planning tends to imagine earthquakes. The incident log says the real threats are closer to the meter: utility power disturbances, UPS battery fires, cooling failures and network hardware faults. A DR site on the same grid, in the same flood plain, behind the same carrier hotel protects against almost none of these. Recent entries:
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
The DR site checklist
- Different utility grid from the primary — verify the actual substation, not the marketing claim
- Outside the primary's flood plain and seismic zone
- Diverse fibre paths: the two sites must not share a carrier hotel or a cable landing
- RTT measured, not estimated — and inside the budget of your chosen replication mode
- Facility certified to the level compliance expects — check the certification directory
- Capacity contractually expandable: a DR site you cannot scale during a real disaster is a decoration
- Remote hands with contractual response times — during a regional event you will not be flying in
- Failover tested end to end before go-live, then annually — a plan is not a capability
Frequently asked
How far apart should primary and DR data centers be?
Far enough to not share a disaster, close enough for your replication mode. The floor is separate utility grids, separate flood plains and separate carrier paths — in practice 50 km or more. Synchronous replication caps the distance at roughly 100 km (about 10 ms round-trip); asynchronous replication removes the ceiling entirely. Many regulators in Asia-Pacific ask for out-of-country DR, which forces async.
What is the difference between RPO and RTO?
RPO (recovery point objective) is how much data you can afford to lose, and it is set by the replication mode. RTO (recovery time objective) is how long you can afford to be down, and it is set by the DR pattern — backup-restore recovers in days, active-active in seconds. Cost scales with both: tightening either by an order of magnitude roughly doubles the DR budget.
Can synchronous replication work between countries?
Only between adjacent ones. Singapore–Kuala Lumpur at ~8 ms RTT supports it; Frankfurt–Amsterdam at ~11 ms is borderline. Anything beyond ~25 ms is asynchronous territory regardless of what the storage vendor datasheet says — every write would carry the round trip, and the application team will feel it before the DR team does.
What actually takes data centers down?
Our incident log is dominated by power events (utility disturbances and UPS failures), fires (lithium-ion battery rooms feature repeatedly), cooling failures and network hardware faults — not regional natural disasters. The practical implication: a DR site in the same metro on the same grid protects against almost none of the incidents that actually occur at facility level, while a site one country over protects against nearly all of them.
Is the public cloud a valid DR site for colocation workloads?
For backup-restore and pilot-light patterns, often yes — you pay for standby capacity only when it runs, which is exactly the cloud pricing model. The catch is egress on the return trip and the operational gap: recovering a colocation estate onto cloud infrastructure means maintaining two deployment targets permanently. Test the full restore, not the replication.
How often should DR be tested?
A full failover at least annually, component restores quarterly, and after every material infrastructure change. An untested DR plan is a document, not a capability — and the incident log shows failures cluster in exactly the mechanisms (power switchover, cooling restart) that only a real test exercises.
Shortlisting a DR market?
Tell us the primary site, the RPO you need and the compliance regime. We will come back with facilities in viable DR markets, benchmark pricing, and the questions worth asking each operator.