Active-passive
A full-size copy of production waits at the DR site, kept in step with the primary. If the primary fails, the passive site takes over within minutes, usually with most of the work automated.
What happens in a disaster
This is what runs at each site on a normal day. Press Simulate a disaster to watch the primary site fail and the DR site take over, step by step.
How the pieces fit together
| Part | What it does |
|---|---|
| 1 Synchronous database replication | A transaction is only confirmed to the user once it is written at both sites. That is what gives near-zero data loss. |
| 2 Synchronous storage replication | Storage arrays or software-defined storage mirror every write to the DR site in the same way. |
| 3 Witness | A small service at a third location that both sites can reach. If the sites lose contact with each other, the witness decides which one stays primary, so both never accept writes at once. |
| Global DNS | Health checks watch both sites and move users to DR when the primary stops responding. |
Synchronous replication has a physical limit. Every write waits for the other site to confirm, and light in fibre adds roughly one millisecond of round trip for every 100 km. That is why synchronous pairs are usually within about 100 km of each other.
That distance protects against a building, power or network failure, but not always against a regional event. Organisations that need both often add a third, distant site with asynchronous replication.
How failover works
- Monitoring or the witness detects that the primary is lost.
- The DR database and storage are promoted to primary, automatically or with one approval.
- The standby application servers connect to the new primary database.
- Global DNS moves users to the DR site.
- Operations confirm transactions are flowing and notify the business.
Failback: Re-establish synchronous replication from DR to the repaired primary, wait until both are in sync, then switch back in a planned window, or simply keep running from the DR site.
When to use it
- Core banking, payments, billing and trading systems
- Telecom and utility operations systems
- Any system where a few minutes of downtime is the limit and data loss must be near zero
When it is not enough
- Sites more than about 100 km apart (use asynchronous replication instead)
- Budgets that cannot carry a full idle copy of production
What to watch out for
- Write latency. Every write now waits for the DR site. Test application performance with synchronous replication on before go-live.
- Split brain. Without a witness, a network cut between sites can leave both thinking they are primary. Always place a witness at a third location.
- Automation you never test. Automatic failover that has not been exercised can fail, or trigger when it should not. Test it at least twice a year.
- Regional events. Two sites close together can be hit by the same flood or grid failure. Consider a third, distant site for the most critical data.
Typical tools for this pattern
Examples only. We recommend tools based on what you already run, your team's skills and your licences.
| Layer | Common choices |
|---|---|
| Database | Oracle Data Guard (Maximum Availability), SQL Server Always On with synchronous commit, PostgreSQL synchronous replication with Patroni |
| Storage | NetApp MetroCluster, Dell PowerMax SRDF, Pure Storage ActiveCluster, Ceph stretch clusters |
| Traffic | Global server load balancing with health checks (F5 BIG-IP DNS, Citrix ADC) |
| Network | Dark fibre or DWDM links with diverse paths between the sites |
Comparing options? See all five patterns side by side in the DR patterns guide, or read what DR really costs.
Not sure where your DR stands?
Send us your application list and a short note on how backups work today. We will come back with a plain gap review: which systems are exposed, what a realistic recovery time looks like, and what it would take to close the gap.