Geographic Redundancy: Designing Across Two Data Centre Sites

What geographic redundancy means

Geographic redundancy means running your systems across two data centre sites far enough apart that one local event cannot take both out. A fire, flood, grid failure or fibre cut near one building should leave the other running.

It is different from redundancy inside a single facility. Dual power feeds, spare cooling units and N+1 designs protect you from equipment failures within one building, but they cannot help if the whole site or precinct is affected. It is also different from a recovery plan on paper. Our guide to disaster recovery for first-time buyers covers recovery targets and planning; this guide focuses on how to design the two-site setup itself.

The distance and latency trade-off

More distance gives better protection from shared risks, but it adds latency between the sites. Light in optical fibre covers roughly 200 kilometres per millisecond, so every 100 kilometres of fibre adds about one millisecond of round-trip time. Real fibre routes follow roads, railways and coastlines, so they are longer than the straight line between two cities.

That matters most for replication. Synchronous replication waits for both sites to confirm each write, so latency slows every transaction. It usually suits sites in the same metro area or a short distance apart. Asynchronous replication sends changes a moment later, which tolerates longer distances but means a small amount of recent data could be lost in a failover. Check the supported latency for your storage, database or virtualisation platform before you pick sites, and ask carriers for measured round-trip times between the two exact buildings rather than a city-to-city estimate.

Common Australian site pairings

Most Australian two-site designs use one of a few patterns. Facility and operator counts below come from the DChunt facility dataset on our coverage page.

• Sydney and Melbourne. The two largest markets, with 105 facilities from 33 named operators in Sydney and 64 facilities from 36 named operators in Melbourne. Roughly 700 kilometres apart in a straight line, they separate risks well and give the widest choice. See our Melbourne guide and the Sydney colocation page. • Sydney and Canberra. About 250 kilometres apart, close enough for lower latency and easy staff travel. Canberra suits government workloads; see our Canberra guide. • Sydney and Brisbane. Useful when users are spread along the east coast. Brisbane has 26 facilities from 16 named operators in our data; see colocation in Brisbane. • Two sites in the same city. Two buildings in different precincts, on separate power and fibre paths, give low latency for synchronous replication. They protect against building-level failures but not a city-wide event, so many organisations add an offsite backup copy as well. • Perth with an east coast site. Western Australian businesses often keep a second site on the east coast. The distance gives strong separation, but latency is much higher, so asynchronous replication is the norm. See colocation in Perth.

Active-active vs active-passive

In an active-active design, both sites run live traffic at the same time. If one fails, the other is already serving users, so recovery can be close to seamless. The catch is complexity: applications must handle data being written in two places, and each site needs enough spare capacity to carry the full load alone.

In an active-passive design, one site runs production and the other waits on standby, either fully built (warm) or with minimal equipment ready to scale up (cold). It is simpler and usually cheaper, but failover takes longer and the standby site can drift out of date if it is not maintained and tested.

Many organisations mix the two: customer-facing services run active-active while internal systems sit active-passive. Decide per application, based on how long it can be down and how much data it can afford to lose.

Make sure the two sites are truly separate

Two sites only add resilience if they do not share hidden dependencies. Before you sign, check:

• Power. Are the sites on different parts of the electricity network? • Fibre. Do your primary and backup links follow physically different routes, or do they meet in the same pit or exchange? Ask carriers for route maps. • Operator. Using one operator for both sites can simplify contracts and interconnection, but a shared control system, staff or process can become a common point of failure. Using two operators spreads that risk. • Supporting services. DNS, identity, monitoring and backups must keep working if either site goes down.

Our guide to connectivity choices explains how to compare carriers, and the comparison tool lets you line up operators side by side.

Test failover, not just backups

A second site is only proven when you have failed over to it. Start with planned switchovers of single applications, then run full-site exercises, and measure how long recovery actually took against your targets. Test failing back to the primary site too, because that step is often forgotten. Repeat tests after major changes. Regulated organisations should check their own obligations: for example, APRA's Prudential Standard CPS 230 Operational Risk Management, in force since 1 July 2025, expects regulated entities to maintain business continuity plans and test them.

Plan your two-site design with DChunt

Start by listing which applications need two sites and their recovery targets, then shortlist city pairings on the DChunt map and compare operators in each. DChunt's free assessment asks about your users, workloads and resilience needs and suggests locations and operators to match. DChunt is independent and does not resell data centre space. This guide is general information, not engineering or compliance advice.