Disaster recovery that has actually been tested
Most organisations have a DR site. Far fewer know how long it really takes to bring their applications back, or whether it works at all. We help you decide what needs protection and how fast it must recover, then design and build it and run the first drill with your team.
Four problems we see again and again
The DR site has never really been used
Replication shows green on the dashboard. But nobody has started the applications at the DR site and checked that a user can log in and complete a transaction.
Everything gets the same protection
A test server gets the same treatment as the core database. The DR bill goes up, and the systems that matter are still not fast enough to recover.
Backups sit next to production
If ransomware, fire or a long power failure hits the main site, the backup copy is lost along with it.
The runbook lives in one person's head
Recovery depends on one engineer remembering the order things start in. When that person is on leave, recovery slows down or stops.
Start with RPO and RTO, not hardware
RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time. An RPO of 15 minutes means that in the worst case you lose the last 15 minutes of transactions.
RTO (Recovery Time Objective) is how long a service can stay down before the damage becomes serious. An RTO of 2 hours means users must be working again within 2 hours of someone declaring a disaster.
Lower numbers cost more. Moving from a 24-hour RPO to 15 minutes usually means replacing nightly backups with continuous replication, which changes the network, the storage and often the software licences. That is why we set these numbers application by application, with the business owner in the room, before anyone talks about servers.
Pick a pattern to see how it works
Each pattern keeps a different amount ready at the DR site. Open one to see its reference architecture and to watch an animated simulation of what happens when the primary site is lost.
Backup and restore
Only backup copies at DR. Servers are built after the disaster.
Pilot light
Data and a small database run at DR. Servers start from templates.
Warm standby
The full stack runs at DR at reduced size and is scaled up.
Active-passive
A full-size synchronised copy takes over within minutes.
Active-active
Both sites serve users. Losing one is close to invisible.
Comparing options side by side? See the DR patterns guide.
How a DR engagement runs
- List the applications and what they depend on. Databases, Active Directory, DNS, file shares, licence servers, integrations, and who owns each application. Missing dependencies are the most common reason a failover stalls.
- Agree RPO and RTO for each application. We sort applications into three or four tiers with the business owners. In most environments only a small share of applications truly needs recovery within a few hours.
- Pick a DR pattern for each tier. Backup and restore, pilot light, warm standby, active-passive or active-active. See how they compare.
- Size the DR site and the network. Replication bandwidth comes from your real daily change rate, not a guess. We show the assumptions so your team can check them.
- Build it and write the runbook. Step-by-step recovery for each tier: who does what, in which order, and how to tell that a step worked.
- Run the first drill. A timed failover of at least one tier. Every issue gets logged and fixed, and you get a drill schedule to keep going.
What you get at the end
- Application inventory with dependencies and tiers
- RPO and RTO sheet signed off by business owners
- Target DR architecture and bill of materials
- Bandwidth and storage sizing, with the assumptions shown
- Recovery runbook for each tier
- Drill report with measured recovery times
Platforms we design for
- VMware, KVM and OpenStack private clouds
- DR from on-premises into AWS, Azure or OCI
- Two data centres, or a data centre plus a colocation rack
- Kubernetes workloads, including persistent volumes
- Database-level replication for Oracle, SQL Server, PostgreSQL and MySQL
Guides and examples
Choosing a DR pattern
Five ways to set up DR, what each costs, and where each one fits.
Read the guide →DR layer by layer
Traffic, network, databases, storage and messaging, with on-premises and cloud equivalents.
Read the guide →HA, fault tolerance and DR
What each one protects against, and why you usually need all three.
Read the guide →DR in the public cloud
Using a cloud region as your DR site: patterns, cost in rupees and the catches.
Read the guide →Keeping DR the same as production
How DR sites drift from production, and how to catch it.
Read the guide →What DR really costs
Where the money goes, rough planning ranges, and a worked example.
Read the guide →DR on OpenStack
How Ceph, Cinder, Neutron and automation fit together for a site failover.
Read the guide →Testing DR
Types of drill, how often to run them, and a checklist for the day.
Read the guide →Use case: hospital group DR
An illustrative scenario: tiered DR for HIS, lab and imaging systems.
Read the use case →DR questions, answered
Backup vs DR, site distance, cloud DR, ransomware and more.
Read the FAQ →For the full technical reference, see the DC-DR whitepaper.
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.