Warm standby
A complete, working copy of the application runs at the DR site every day, just at a smaller size. Because it is already running, you know it works. On failover you scale it up and send users to it.
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 Database replication | The DR database is a continuously updated replica. It is sized to take the full production load as soon as it is promoted. |
| 2 Storage replication | Application data is copied asynchronously, normally seconds to a few minutes behind. |
| 3 Release pipeline | Every release is deployed to both sites. This is what keeps the DR copy identical to production instead of drifting over time. |
| Health checks | The global DNS or load balancer checks the DR application continuously, so a broken standby is noticed on a normal Tuesday, not on disaster day. |
The difference from pilot light is that every tier is already running at DR. Nothing has to be built on the day, only enlarged. That removes the biggest source of surprises, and many teams send a small amount of real or test traffic to the DR copy to prove it works.
The trade-off is cost and discipline. You pay for a running environment every day, and every change must reach both sites or the standby slowly stops matching production.
How failover works
- Declare the disaster.
- Promote the DR database replica to primary.
- Scale web and application tiers from one server to full size, from reserved capacity or an autoscaling group.
- Confirm health checks are green and run a short user test.
- Switch the global DNS or load balancer to the DR site.
Failback: Rebuild replication from DR back to the primary, let it catch up, then switch over in a planned window and scale DR back down.
When to use it
- Customer portals and citizen-facing services
- Hospital information systems, large ERP platforms
- Systems where the business can tolerate one to two hours of downtime at most
When it is not enough
- Systems that need recovery in minutes with near-zero data loss
- Environments without a disciplined release process
What to watch out for
- Capacity on the day. On-premises, the hardware for full size must exist at DR. In the cloud, reserve capacity or check quotas, because everyone scales up at once in a regional event.
- Release drift. If a release goes to production but not DR, failover brings up last month's application. Put DR in the pipeline, not in a manual checklist.
- Database size. A small DR database saves money but must be resized before it can take full write load. Decide whether you can afford that delay.
- Cost creep. Running DR instances tend to grow. Review their size every quarter.
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 |
|---|---|
| Traffic switching | Global server load balancing (F5, Citrix ADC), cloud DNS failover with health checks |
| Scaling | VM autoscaling groups, Kubernetes horizontal scaling, reserved capacity |
| Release pipeline | GitLab CI, Jenkins, Argo CD deploying to both sites |
| Replication | Database-native replication plus storage or volume replication |
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.