Data center disaster recovery and business continuity field guide

What disaster recovery and business continuity are

Disaster recovery is the part of a continuity program that restores the IT systems and data after a disruption. Business continuity is the larger plan that keeps the whole organization running through that disruption: the people, the facilities, the processes, and the technology. DR sits inside BC as the technology piece. Restore the servers and you have done disaster recovery. Keep the business answering phones, taking orders, and meeting its obligations while those servers come back is business continuity.

On a data center project the two terms get used loosely, and the loose use causes real gaps. A team can build a clean DR capability, replication running and a recovery site ready, and still have no continuity plan for the staff who cannot reach the building or the process that leaned on a vendor who is also down. The reverse happens too: a continuity binder full of phone trees with no actual way to bring the systems back inside the time the business assumed.

This guide stays on the data center side, the DR itself, and where it meets the wider BC plan. The within-site redundancy that keeps a single building up, the tier and the N-plus-one arrangement, is a separate layer covered in the data center tier classification and uptime guide. Disaster recovery is what you reach for when that layer is not enough, when the whole site is gone.

What is the difference between disaster recovery and business continuity?

The difference is scope. Business continuity is the whole organization staying operational through a disruption. Disaster recovery is the recovery of the IT systems and data the organization runs on. DR is a subset of BC, the technology slice of a much wider plan.

They differ in timing and posture too. Business continuity tends to be proactive and runs the moment a disruption starts, keeping the important functions alive on whatever workaround exists. Disaster recovery is reactive: it kicks in after the event and stays in motion until systems and data are back to a working state. One keeps the business moving. The other repairs the thing the business moves on.

Build them together. A DR plan that hits its recovery targets is wasted if the business never worked out how to operate during the hours or days the recovery takes. A continuity plan is fiction if the IT recovery behind it cannot actually meet the times the plan assumed. The business impact analysis is the document that ties the two, and it is where both should start.

Why one site is never enough

A single site will fail eventually. Not might, will. The cause varies, a flood, an earthquake, a fire, a long utility outage, a fiber cut that isolates the building, a regional event that takes out power for a county, but the conclusion does not. Plan for the loss of the whole site, because over a long enough horizon you get it.

This is the distinction owners miss most. Redundancy inside a site is not the same as surviving the loss of the site. A Tier IV building with 2N power and continuous cooling rides through any single failure inside its walls, and it is still one building. A fire in the right room, a flood at the right elevation, or a regional grid event takes the whole thing, 2N and all. Site resilience and geographic resilience are two different problems, solved by two different layers.

So think in two layers. The first is within-site resilience, the tier and the redundancy that keeps one building up through its own faults, covered in the data center tier classification and uptime guide. The second is disaster recovery, a separate location far enough away that the same disaster cannot reach it. The tier handles the failure inside the fence. DR handles the loss of everything inside the fence. You need both, and buying a higher tier does not buy you the second one.

The disaster scenarios you plan against

DR planning starts with a clear-eyed list of what can take the site. Group the threats and the plan gets easier to size, because different threats hit different parts of it.

Natural events are the obvious ones: flood, earthquake, hurricane and severe storm, wildfire, and the fire that starts inside the building. These tend to take the whole site at once, which is why they drive the geographic-separation decision. Put the recovery site in the same flood plain or the same seismic zone and one event takes both.

Infrastructure threats are quieter but more common. A utility outage that outlasts the generator fuel. A network or fiber cut that isolates a site that is otherwise fine. A cooling failure that, at high density, cooks the hall in minutes. The building is physically intact and still down, which is its own kind of disaster.

Then the man-made ones, and these now dominate the statistics. Cyberattack and ransomware, where the systems are up but the data is encrypted or gone. Human error, the fat-fingered command or the bad change that takes production down. And plain equipment failure that lands past what the on-site redundancy was built to absorb. A modern DR plan treats ransomware as a first-class scenario, not a footnote, because it attacks the recovery itself by going after the backups.

What are RTO and RPO?

RTO and RPO are the two numbers that size every DR plan. The recovery time objective is how fast a system must be back after an outage, the maximum downtime the business will accept. The recovery point objective is how much data the business can afford to lose, measured as time back to the last good copy. RTO is about speed. RPO is about data loss.

Read them off a timeline with the disaster in the middle. RPO sits to the left, in the past: an RPO of 15 minutes means the recovered system can be up to 15 minutes stale, so you must capture data at least that often. RTO sits to the right, in the future: an RTO of two hours means the system has to be serving again within two hours of going down. The two are independent. A system can need near-zero data loss and tolerate a slow recovery, or the opposite.

These are business decisions, not IT preferences. The business says what an hour down costs and what an hour of lost data costs, and those answers set the targets. Set them per system, because they vary wildly. The order ledger may need an RPO of seconds, while the internal wiki can lose a day and nobody notices. The business impact analysis is where these numbers come from.

Backup, cold, warm, and hot sites

The recovery options form a ladder from cheap and slow to expensive and instant, and the RTO and RPO you set decide which rung you need. Tighter targets cost more. There is no free fast recovery. The whole strategy is choosing the lowest rung that still meets the time the business will accept.

Backup and restore is the bottom: offsite backups, and when the site is gone you rebuild on new or borrowed hardware and restore the data. Cheapest to keep, slowest to recover, measured in days. A cold site is an empty ready facility, with space, power, and cooling but no live equipment standing by, so you still install and restore before you run. A warm site has the hardware in place and data kept partially current, so recovery is hours, not days. A hot site is a fully running mirror with data replicated continuously, ready to take the load on near-instant failover, recovery in minutes or less, at the highest cost. Above all of that sits active-active, both sites live and sharing the load, where a site loss is absorbed with almost nothing to do.

The mistake is buying a rung by reputation instead of by RTO. A workload that can wait until morning does not need a hot site, and paying for one is money spent retiring a risk the business never carried. A workload that loses real money every minute cannot live on backup-and-restore, and discovering that during the outage is the expensive way to learn it.

Active-active and active-passive

Two sites can be arranged two ways, and the choice sets both the recovery speed and the cost. Active-passive keeps a primary site live and a standby site idle, ready to take over when the primary fails. Active-active runs both sites live at the same time, sharing the production load, so neither is a spare.

Active-passive is the simpler build and the cheaper one, but it pays for a standby that earns nothing until something breaks, and the failover carries a short delay, commonly tens of seconds, while the standby picks up. Active-active puts every site to work, so the hardware is always earning, and a site loss is absorbed near-instantly because the surviving site is already carrying traffic. The price is complexity. Running the same workload live in two places means solving data consistency, split traffic, and the risk that the two sides diverge.

Active-active maps to the shortest RTO and the hot-site or better end of the ladder. Active-passive covers the large middle where a brief, controlled failover is acceptable and running two full live systems is not worth the complexity. Most enterprise DR lands in active-passive. Active-active shows up where the recovery has to be invisible and the budget and the engineering can carry it.

Synchronous and asynchronous replication

Replication is how data gets to the recovery site, and the mode you pick sets the RPO. There are two, and the difference is whether the primary waits for the copy. Synchronous replication writes to both sites before it tells the application the write is done, so the two copies are always identical. Asynchronous replication acknowledges the write locally and ships it to the far site a moment later, so the copy trails slightly behind.

Synchronous gives you an RPO of zero, no data loss, because nothing is acknowledged until it is in both places. The catch is distance. Every write waits for the round trip to the far site, so latency climbs with distance and the application slows. That holds synchronous replication to short hauls, commonly within roughly 100 km or metro range over a low-latency link. Push it farther and writes stall or the link cannot keep up.

Asynchronous gives up a little RPO, seconds to minutes of possible loss, in exchange for distance. It works over a wide-area link across the country or between cloud regions, because the primary never waits on the far end. For geographic separation that survives a regional disaster, asynchronous is usually the only practical mode, and you accept a small RPO as the price of putting the sites far enough apart to matter. Match the mode to the RPO and the distance, and confirm the link can actually carry the change rate.

Geographic redundancy and multi-region

Geographic redundancy means putting the recovery site far enough from the primary that one disaster cannot reach both. The distance is the whole point. Two sites on the same flood plain, the same power grid, or the same fiber path are not geographically redundant no matter how far apart they look on a map, because the event that takes one takes the other.

In the cloud this shows up as regions and availability zones, and the difference matters for DR. An availability zone is a separate physical location within a region, usually some miles apart, isolated for power and cooling but close enough for low-latency links. Spreading across zones survives a single data center failure, a power outage or a fire in one building. It does not survive a regional event, because the zones still share region-wide services and sit in the same geography. Surviving the region means running in a second region, far away, which is the cloud version of the second site.

The tradeoff is the same one replication raises. More distance buys more independence and costs more in latency, complexity, and often a duplicated environment. A multi-region strategy can roughly double the running cost. The honest design separates the sites enough that a realistic regional disaster, a hurricane, a grid collapse, a wide flood, cannot take both, and no farther than the recovery targets and the budget justify.

What is the 3-2-1 backup rule?

The 3-2-1 backup rule is the floor for backup design: keep three copies of your data, on two different types of media, with at least one copy offsite. Three copies so a single loss leaves you two. Two media so one media failure does not take all copies. One offsite so a disaster at the primary site does not take the backups along with the production they were protecting.

The rule predates ransomware, and that gap is where it gets extended. Modern practice adds an immutable or air-gapped copy, written 3-2-1-1-0: the extra 1 is the locked copy and the 0 is zero recovery errors, proven by testing the restores. Immutable means the copy cannot be changed or deleted for a set retention period, enforced by the storage, for example with object lock. Air-gapped means the copy is physically or logically disconnected, out of reach of the network entirely.

The reason is blunt. Ransomware goes after the backups first, because attackers know a clean backup is what lets you refuse to pay. A backup that sits online, reachable with the same credentials as production, is not a backup against ransomware. It is one more thing the attacker encrypts. The copy that saves you is the one the attacker could not touch. Test the restores too, because a backup you have never restored is a hope, not a recovery.

Ransomware and the cyber-recovery vault

Ransomware changed what DR has to defend against, and most plans built for fire and flood do not cover it. A natural disaster destroys the site and leaves the data intact somewhere else. Ransomware leaves the site standing and destroys the data, including, if it can reach them, the backups and the replicated copies. Replication can even help the attacker, faithfully copying the encrypted data to the recovery site.

That breaks the assumptions behind ordinary DR. You cannot fail over to a hot site whose data is the same encrypted data as production. You cannot restore from a backup the malware reached and corrupted. So cyber recovery is treated as its own discipline alongside disaster recovery, built around copies the attacker cannot alter. The cyber-recovery vault is the pattern: an isolated environment with separate credentials and authentication, immutable storage, and restricted access, holding clean copies that are checked for integrity and known good.

The practical asks are specific. Keep at least one immutable or air-gapped copy on a separate trust domain, not reachable with production credentials. Keep enough history that you can recover to a point before the intrusion, because ransomware often sits quiet for weeks before it triggers. And rehearse the clean recovery, validating that the data is uncompromised, not just present. A restore that brings back the malware is not a recovery.

The DR plan and runbooks

A DR plan is a written, current document, not a shared understanding. When the site is down at 2 a.m. and half the people who built it are unreachable, the plan is what someone follows step by step. If it lives in one engineer's head, the plan is that engineer's availability, which is not a plan.

What it has to contain is concrete. The roles: who declares a disaster, who runs the recovery, who talks to the business. The contacts: current, with backups, including vendors and the people who can authorize spending. The runbooks: the actual step-by-step procedures to bring each system back, written so someone who is not the original owner can run them. And the order of recovery, which is the part most often missed.

Order matters because systems have dependencies. Bring up the application before the database it reads, or before authentication, or before the network it rides on, and it fails and you waste time you do not have. The plan has to sequence recovery by dependency: foundation services first, then the systems that lean on them, in the order the business impact analysis prioritized. Write the dependencies down, because under pressure people forget the boring one that everything else needs.

How do you test a DR plan?

You test a DR plan by running it, on a schedule, before you need it. An untested plan does not work, and that is not pessimism, it is what testing finds every time. Systems drift, runbooks go stale, contacts leave, a restore that was supposed to take two hours takes eight. You want to find that in a drill, not in a disaster.

There are two levels, and you do both. A tabletop test walks the team through the plan on paper, role by role, surfacing the gaps and the stale assumptions cheaply, with no systems touched. A full failover test actually moves production to the recovery site and runs on it, which is the only way to prove the RTO and RPO are real and not aspirational. Tabletops are frequent and cheap. Full failovers are harder to schedule and worth far more, because they test the thing instead of the description of the thing.

Test on a cadence and after major change, and treat every finding as a fix, not a one-off. The point is not to pass the test. The point is to find what breaks while it is safe to break it. A plan tested once at handover and never again is back to untested within a year, because the environment it described has moved on.

Failover and failback

Failover is switching production to the recovery site. Failback is returning it to the primary once the primary is healthy again. Both are part of the plan, and the second one is the part that gets skipped.

Failover gets the attention because it is the emergency move, and a good plan makes it as automatic and rehearsed as possible, with clear triggers for who declares it and when. But failover is only half the round trip. After the disaster passes and the primary site is rebuilt or restored, you have to bring production home, and that move has its own risks. The data written at the recovery site while you ran there has to be synchronized back to the primary, in the right direction, without losing the work done during the outage.

Plan and rehearse failback with the same care as failover. The common failure is a team that drilled the failover, ran on the recovery site through the event, and then improvised the return under pressure, overwriting good data or causing a second outage on the way home. Decide in advance how data reconciles, in what order systems move back, and how you confirm the primary is truly ready before you trust it again.

Cloud DR and DRaaS

The cloud changed the economics of DR, mostly by removing the second building you used to have to own. Instead of leasing a cold or warm site and stocking it with hardware that sits idle, you can keep a small footprint in another region and scale it up only when you fail over, paying for the standby capacity at a fraction of owning it.

Disaster recovery as a service, DRaaS, packages this. A provider hosts the recovery environment and the replication and handles the failover, so a smaller organization gets a capability it could not build alone. Hybrid patterns are common too, an on-premises primary replicating to the cloud as the recovery target, which gives geographic separation without a second physical site. The pricing model fits DR well: you pay little while idle and more only during an actual or tested failover.

The cloud does not remove the work, it relocates it. You still set RTO and RPO, still choose the replication mode and the region for real geographic separation, still write and test the plan. And you inherit cloud-specific failure modes, a region-wide service outage, a misconfiguration that deletes across zones, an account compromise that reaches the backups. Multi-region separation and immutable copies apply in the cloud for the same reasons they do on the ground.

The business impact analysis

The business impact analysis is where DR planning should start, because it produces the priorities everything else depends on. The BIA goes through the organization's activities and works out what a disruption costs each one over time, in money, in risk, in legal and contractual obligation. Out of that comes the ranked list of critical systems and, for each, an RTO and an RPO.

Without a BIA, every system looks equally important, which means none of them have a recovery order and the plan is a guess. With one, you know the order ledger has to be back in 15 minutes with seconds of data loss while the training portal can wait two days, and you can size the recovery, and the spend, to match. The BIA is what turns DR from a flat list of servers into a priced, sequenced plan.

In the formal frameworks the BIA is a named requirement. Under ISO 22301, the business continuity standard, the business impact analysis drives the continuity strategy, and it is also where the related figure called the maximum tolerable period of disruption gets set, the outer limit the RTO has to stay inside. Whether or not you certify to a standard, the discipline is the same: rank by impact, then plan to the ranking.

Operations, incident response, and DR

A DR plan is only as good as the operations team that runs it, and DR has to connect to how the site is operated day to day. The same disciplines that keep a data center running, the documented procedures and the trained staff, are what make a recovery go right under pressure. A recovery run by people improvising is a recovery that misses its targets.

Tie DR into incident response. The declaration of a disaster is an escalation off the normal incident path, and the handoff has to be clear: who decides this is no longer a routine incident and is now a DR event, and what changes when they do. The procedures that govern controlled work in a live facility, the method of procedure and the emergency operating procedure, are the same kind of documents a recovery runs on, and the people who execute them are the same people.

The broader commissioning and operations program is where this lives, covered in the data center commissioning operations overview guide. The point here is narrow. DR is not a binder that sits on a shelf apart from operations. It is operations doing something rehearsed under bad conditions, and it works only if the operations program made it rehearsed.

AI and large-scale loads change the DR math

The AI build-out is reshaping DR the way it reshaped cooling, by changing the scale and the cost of the thing being protected. Training and inference clusters represent enormous concentrated value and enormous data volumes, and the question of how you recover them, and how much state you can afford to lose, is being worked out as the loads grow.

A few pressures are clear even where the practice is still settling. The data volumes make replication bandwidth and backup windows a real constraint, so the RPO you can actually achieve may be set by what the link and the storage can move, not by what you would like. The concentrated value raises the stakes on a regional event, pushing more workloads toward genuine geographic separation. And the cost of the hardware makes an idle hot-site duplicate of a large cluster hard to justify, which pushes designs toward checkpointing and restart rather than a second running mirror.

Treat this as a topic still in motion rather than a solved pattern. The metrics do not change, RTO and RPO and the BIA still drive it, but the right architecture for recovering a very large AI workload is an active design question. The honest move is to size it to the specific workload and its data rate, not to copy a pattern built for conventional enterprise systems.

What to document

DR is only defensible when the plan is written down and traceable to the business need. The single most useful artifact is a table that ties each critical system to its RTO and RPO, its recovery option, and its dependencies, so a reviewer can walk it and find the place where the plan and the reality part ways.

Capture, per critical system, the business function it supports, the RTO and RPO the business signed off, the recovery option that meets them, the dependencies that set its place in the recovery order, and the date and result of the last test. The row that should stop a review cold is any critical system with a tight RTO and a recovery option that cannot meet it, or a last-test date that is blank or years old.

Common mistakes

• Confusing site redundancy with disaster recovery, running one site at a high tier and no second location.
• Operating with no defined RTO and RPO, or numbers so loose they drive nothing.
• Keeping a DR plan on paper and never running a failover test, so nobody knows if it works.
• Storing backups online and reachable, with no immutable or air-gapped copy, then losing them to ransomware.
• Stretching synchronous replication past the distance the latency allows, so writes stall or the link drops.
• Skipping the business impact analysis, so every system is treated as equally critical and nothing has a recovery order.
• Planning the failover and never planning the failback, then improvising the return under pressure.

Field checklist

Standards and references

ISO 22301 is the international standard for business continuity management systems. It sets the framework for building and running a continuity program, and it is where the business impact analysis is a named requirement that drives the continuity strategy. The related guidance, including ISO/TS 22317 on the BIA, fills in how to do the analysis. If an organization certifies its continuity program, this is usually the standard it certifies to.

On the audit side, SOC 2 examinations commonly look at availability and at whether a tested DR and backup capability exists, which is why customers in regulated or contractual relationships often ask for evidence of DR testing. Sector regulators in finance, healthcare, and government add their own continuity and recovery requirements. Treat these as drivers of the plan, and confirm the specific obligation against the organization's actual regulatory and contractual commitments rather than assuming a generic rule applies.

For backup design, the 3-2-1 rule and its 3-2-1-1-0 extension are widely used industry practice rather than a single governing standard, and the immutable or air-gapped copy is the part that addresses ransomware. The within-site resilience that DR complements is governed separately by the Uptime Institute Tier Standard and ANSI/TIA-942, covered in the data center tier classification and uptime guide. Standards and regulatory requirements evolve, so verify the current edition and the organization's specific obligations against the project basis of design before treating any of these as the controlling document.

Terms and how they are used

The DR vocabulary is precise, and the same idea shows up under different labels across a continuity plan, a storage spec, and an audit report. Keeping the terms straight is most of the work on this subject.

RTO and RPO are the two targets, recovery time and recovery point, time-to-back and data-loss. Failover and failback are the two moves, out to the recovery site and back to the primary. The site ladder runs backup, cold, warm, hot, and active-active, from slowest and cheapest to fastest and dearest. Synchronous and asynchronous describe the replication, zero data loss at short range versus some data loss at any distance. And the 3-2-1 rule, extended to 3-2-1-1-0, governs the backups.

RTO

Recovery time objective, the maximum tolerable downtime before a system must be restored

RPO

Recovery point objective, the maximum tolerable data loss, measured in time back to the last good copy

Failover / failback

Switching production to the recovery site, and returning it to the primary after recovery

Hot site

A fully running mirror with continuous replication and near-instant failover

Synchronous / asynchronous

Replication that confirms at both sites for zero RPO at short range, versus trailing copy for any distance

3-2-1 rule

Three copies, two media, one offsite; extended to 3-2-1-1-0 with an immutable copy and tested restores

BIA

Business impact analysis, ranking systems by the impact of their loss and setting each one's RTO and RPO

DRaaS

Disaster recovery as a service, the recovery environment and failover hosted by a provider

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What are data center tiers?
• What is commissioning in construction?
• What is data center waste heat reuse?
• Cast-in vs post-installed anchors: which should I use?
• What is the difference between cold and hot commissioning of a BESS?