A plan that has been tested is the only kind worth having
A second site, a cloud target, or both — designed against agreed recovery time and recovery point objectives, then actually tested, with the runbook written for the person who will be holding it at three in the morning.
Disaster recovery, end to end
Business impact review
Which systems must come back first, and how long the business can genuinely operate without each. This is a business conversation before it is a technical one.
Recovery objectives
RTO and RPO agreed per system and written down. Everything downstream is engineered against these two numbers.
Second site or cloud
Replication to a secondary data centre, to a cloud target, or a hybrid. Sized so the recovery objective is achievable, not aspirational.
Replication and failover
Hypervisor or array replication, orchestrated failover where it is justified, and a documented manual path where it is not.
The runbook
Step by step, written for someone under pressure, including who decides to invoke it and who to call. Most plans fail on the decision, not the technology.
Testing
Scheduled failover tests with results recorded and the runbook corrected afterwards. Every test finds something.
Impact, objectives, build, test
1. Impact
Systems ranked by what breaks in the business when they stop. Not by how much the server cost.
2. Objectives
RTO and RPO per system, agreed with the people who carry the consequence.
3. Build
Replication, target capacity, networking and the identity and DNS dependencies that quietly decide whether a failover works.
4. Test and maintain
A real test, a corrected runbook, and a review whenever the environment changes. A plan that describes last year’s estate is not a plan.
The failures we are called in to fix
- The plan was never tested. It was written, approved, filed, and has never once been executed. Nobody knows if it works, including the people who signed it.
- The dependencies were missed. The application replicates, but the domain controller, the DNS, the licensing server or the firewall rules do not. The system comes up and cannot be reached.
- The objectives were never agreed. IT assumed four hours, the business assumed thirty minutes, and nobody discovered the gap until the day it mattered.
- Nobody owns the decision. The technology is ready and three hours are lost deciding whether to invoke. We name the decision-maker in the runbook.
Common questions
Is backup the same as disaster recovery?
No. Backup gets the data back. Disaster recovery gets the business running. You need both, and they are sized differently.
Do we need a second site?
Not always. A cloud recovery target is often cheaper and faster to stand up. The right answer comes from the recovery objectives, not from the brochure.
How often should we test?
At least annually, and after any significant change. A test that has not happened since the last major upgrade tells you about an estate that no longer exists.
Will an auditor ask for this?
Yes. Business continuity and tested recovery are explicit controls in ISO 27001 and SOC 2. Our compliance team produces the evidence.
Tell us which system you cannot run the business without.
Start with one. We will work out what it truly depends on, and what recovering it would actually take today.
02 3537 5791