Pilot light
Keep the parts that are hardest to rebuild, your data and your database, alive at the DR site all the time in a small form. Everything else exists as ready templates that are switched on only when needed.
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 Server templates | Golden images of the web and application servers are refreshed at DR after every patch cycle or release. The servers themselves stay switched off. |
| 2 Database replication | Changes stream continuously from the primary database to a small replica at DR. The replica is read-only until it is promoted. |
| 3 Directory replication | A domain controller and DNS server run at DR all the time. Almost every application depends on them, and they are slow to rebuild from scratch. |
| 4 Storage replication | Application volumes are copied asynchronously to the DR storage, a few seconds to minutes behind production. |
The name comes from gas boilers: a small flame stays lit so the full burner can be started quickly. Here, the small flame is the replicated data and database. Because the data is already at DR and current to within minutes, recovery is mostly about starting servers, not restoring terabytes.
What decides the recovery time is how the stopped servers get started. If it is done by hand, it can take a day. With automation (Terraform, Heat or Ansible) and current templates, it is usually a few hours, most of which is testing.
How failover works
- Declare the disaster.
- Promote the database replica to primary and increase its size to production capacity.
- Run the automation that starts web and application servers from the current templates.
- Attach the replicated volumes and start services in dependency order.
- Run health checks and a short test with application owners.
- Switch DNS or the global load balancer to the DR site.
Failback: Reverse the replication so the rebuilt primary catches up from DR, then do a planned switchover back in a maintenance window.
When to use it
- Core business systems that can be down for half a day, but cannot lose a day of data
- ERP, HR and payroll, internal portals, e-commerce back office
- Organisations that want real DR without paying for a second running copy
When it is not enough
- Systems that must be back within an hour
- Applications that cannot be built automatically and need long manual set-up
What to watch out for
- Stale templates. If the DR images miss last month's patches or configuration changes, servers start but applications fail. Refresh them as part of every release.
- Untested automation. Scripts that have never run in anger usually fail on the first try. Run them in every drill.
- Scaling the database. On-premises, the hardware to run the database at full size must already be at the DR site.
- Secrets and certificates. Make sure TLS certificates, keys and service passwords are available at DR, not only in the primary vault.
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 replication | Oracle Data Guard, SQL Server Always On (asynchronous), PostgreSQL streaming replication, MySQL replication |
| Storage replication | Ceph RBD mirroring, storage-array asynchronous replication, cloud volume replication |
| Templates and automation | Packer for images, Terraform, OpenStack Heat, Ansible |
| Directory | Additional AD domain controller and DNS server at DR |
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.