Disaster Recovery: Sites and Test Types

Disaster recovery: sites and test types. This is the last lesson of Domain four, and it brings the recovery objectives, the site choice, and the discipline of testing together.

Two facts sit in the disaster recovery file. The recovery site is a cold site, chosen because it was the cheapest option, and the organisation’s most critical system has a recovery time objective of two hours. And the plan itself, forty careful pages, has never once been tested. On paper, there is a D-R capability. Read the two facts together, and there is a system that must be back in two hours, a site that takes days to stand up, and no evidence any of it works.

Start with sites. Where you recover to is a trade-off between cost and how fast you can be running again, and the choice is driven by the R-T-O from lesson eleven.

A hot site is fully equipped, with systems and current data ready to take over almost immediately. Fastest recovery, highest cost. It is what a short R-T-O demands.

A warm site is partially equipped, some infrastructure in place, data restored on activation. Recovery in hours to a day, moderate cost. It suits a moderate R-T-O.

And a cold site provides only space, power and connectivity; equipment and data must be brought in and built up. Cheapest, and slowest, days to activate. Only acceptable for a long R-T-O. There is also a mirrored or fully redundant site, running in parallel with near-real-time data, for effectively immediate failover at the highest cost.

So the cold site in our scenario is the finding. Chosen on price, it cannot possibly meet a two-hour R-T-O. The site must fit the objective, and a critical, low-R-T-O system justifies the expense of a warm or hot site. Choosing by cost alone, ignoring the R-T-O, is the wrong answer.

Now testing, because a D-R plan is only proven by testing, and the test types form a ladder, from least to most rigorous, and from least to most risky. Assurance and risk rise together as you climb it.

At the bottom, the checklist, or desk review, checks the plan on paper for completeness, and the structured walkthrough has the recovery team talk through it together. Lowest effort, lowest assurance, no system is actually recovered.

Next, simulation: the team role-plays a disaster scenario and their response, without affecting production.

And at the top, the parallel test brings the recovery systems up at the alternate site alongside production and compares outputs, and the full-interruption test actually fails production over to the recovery capability. These give the strongest assurance, they prove recovery genuinely works, and they carry the most risk, because a failed test disrupts live operations.

Underneath both choices is the discipline our scenario is missing entirely: the plan has never been tested. A D-R plan is full of assumptions, dependencies, data that must restore, steps timed on optimism, and only testing exposes them while it is still safe to fix them. Until it has been tested, there is no assurance the plan works, and a real disaster is the worst possible moment to discover it does not. It is the untested rollback from Domain three, and the unexercised continuity plan from the last lesson: an untested fallback is a hope, not a control.

So carry this away, and it closes the domain. Match the recovery site to the R-T-O, not to the budget, a cold site cannot serve a critical, low-R-T-O system however cheap. The more rigorous the test, the more assurance and the more risk. And an untested D-R plan, like an untested backup, proves nothing at all. That completes Domain four.