How Should Businesses Design a Secondary Disaster Recovery Site?

Quick answer

A secondary disaster recovery (DR) site is an alternate facility — physical or cloud-based — where a business restores critical systems and data after its primary site fails. Designing one means running a business impact analysis to set Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets, choosing a site type (hot, warm, or cold) that matches those targets and budget, selecting a location far enough from the primary site to avoid sharing the same risk, building a replication strategy, and testing failover regularly. Most mid-size organizations land on a warm site or a cloud-based DR-as-a-Service model rather than a fully mirrored hot site.

What Is a Secondary Disaster Recovery Site?

A secondary disaster recovery site is a facility — on-premises, colocated, or cloud-hosted — that an organization switches operations to when its primary data center becomes unavailable because of a natural disaster, hardware failure, cyberattack, or human error. It differs from a simple backup: a backup stores copies of data, while a DR site provides the compute, network, and operational environment needed to actually run the business again.

This guide is written for IT directors, business continuity managers, and operations leaders who are building or re-evaluating a disaster recovery strategy for a mid-size to large organization.

Why Businesses Need a Secondary Disaster Recovery Site

Outages are no longer rare edge cases. Server failures, ransomware, power loss, and extreme weather can take primary data centers offline for hours or days. U.S. government business-continuity guidance recommends defining recovery priorities, RTOs, and recovery strategies before an incident occurs.

Regulated industries face additional requirements. Financial services, healthcare, and critical-infrastructure organizations may need to demonstrate documented and tested recovery capabilities. ISO 22301 also establishes a framework for preparing for, responding to, and recovering from disruptive incidents.

The financial impact can be substantial. Uptime Institute's 2024 Annual Outage Analysis found that many significant outages resulting in business disruption cost more than $100,000, with some exceeding $1 million.

In short: A secondary DR site helps businesses limit downtime, protect critical data, and demonstrate recovery readiness—turning an unpredictable outage into a planned and measurable recovery process.

Real-World Example: Why Geographic Dispersion Matters

The 2017 NotPetya attack on Maersk illustrates why recovery infrastructure must be isolated from the primary environment.

The malware wiped out nearly all of Maersk’s roughly 150 domain controllers. Administrators eventually discovered that one domain controller in a Ghana office had survived because a local power outage had disconnected it from the network when the attack occurred. That isolated copy became a crucial starting point for rebuilding Maersk’s IT environment.

Maersk ultimately rebuilt approximately 4,000 servers and 45,000 PCs in 10 days, while the full recovery took considerably longer. The incident was estimated to have cost the company roughly $250–300 million.

The lesson for DR design is clear: geographic separation and network isolation can be critical when a disaster affects the primary environment at scale. A secondary site should not simply replicate production—it should remain sufficiently independent to survive the same incident.

Types of Disaster Recovery Sites: Hot, Warm, and Cold

Every DR site design reduces to one trade-off: how much readiness has been paid for in advance. The three classic models sit on a spectrum from always-on to built-from-scratch.

 Cloud-based Disaster-Recovery-as-a-Service (DRaaS) increasingly blurs these categories, letting a business pay warm-site prices for standby infrastructure while retaining the option to scale up to hot-site performance only when a failover actually occurs.

Decision Framework: Four Questions That Pick Your Site Type

Rather than starting from a budget or a vendor pitch, work through these four questions in order — each one narrows the choice further, and together they function as a simple flowchart for the decision:

1. What is the Maximum Tolerable Downtime for this system? If it's measured in minutes, a cold site is already disqualified regardless of price.

2. Can the business absorb the RPO of a scheduled backup, or does it need continuous replication? Hours of tolerable data loss point to warm; near-zero data loss points to hot or CDP-based replication.

3. Does the budget support standing infrastructure, or only pay-as-you-go? A constrained budget with a demanding RTO usually points to cloud DRaaS rather than a self-built hot site.

4. Is the workload regulated or data-residency-restricted? If so, the site location and hosting model are partly decided before cost or speed even enter the conversation.

In short: the site type is a downstream decision, not a starting point — it should fall out of the answers to these four questions, not the other way around.

Key Metrics to Define Before Designing: RTO and RPO

Before choosing a site type, determine how much downtime and data loss the business can tolerate.

• Recovery Time Objective (RTO): The maximum acceptable time to restore a system after a disruption.

• Recovery Point Objective (RPO): The maximum acceptable amount of data loss, measured backward from the point of failure.

According to NIST Special Publication 800-34, RTO and RPO should be derived from the business impact analysis. The RTO for each system should also remain shorter than its Maximum Tolerable Downtime (MTD).

Set Different Targets for Different Systems

Not every workload needs the same recovery objectives. For example:

Tiering systems this way prevents businesses from over-engineering the DR site for less-critical workloads while ensuring critical systems receive the resources they need.

Make Sure the Design Can Actually Meet the RPO

RPO must be reflected in the actual replication or backup strategy.

For example, if a system has an RPO of 15 minutes, its replication or backup process needs to capture recoverable data at least every 15 minutes. A longer interval means the stated RPO cannot reliably be achieved.

The key principle: RTO and RPO should drive the DR design—not the other way around. A recovery target is only meaningful if the underlying infrastructure can actually meet it.

How Should Businesses Design a Secondary Disaster Recovery Site?

1. Run a Business Impact Analysis

Identify critical business processes, the systems that support them, and the financial or operational cost of losing each one per hour of downtime. The output is a ranked list of systems with an RTO and RPO attached to each — the foundation every later decision is built on.

2. Choose the Site Type and Deployment Model

Match the RTO/RPO tiers from Step 1 against the hot/warm/cold comparison above, then decide how the site will be hosted: a company-owned secondary data center, a colocation facility, or a cloud DRaaS subscription. Cloud models generally lower upfront capital cost and are easiest to scale, while owned or colocated sites give more control over data residency and network architecture.

3. Build the Data Replication and Synchronization Strategy

This step decides whether the RPO target on paper is achievable in practice. For systems that tolerate hours of data loss, scheduled backups replicated to the secondary site are enough. For systems with a near-zero RPO requirement, scheduled backups are too slow, because the gap between backup windows becomes the maximum data loss.

4. Plan Network and Bandwidth Capacity

Replication traffic between sites needs dedicated, sized bandwidth — undersized links are one of the most common reasons a DR site misses its RPO in practice. Model peak change-rate volume, not average, and build in headroom for growth and for the initial full data seed.

Rule of thumb: divide the daily data change volume by the target replication window, then add roughly 30-50% headroom for peak periods and future growth. A system generating 480 GB of daily change that must replicate within a 4-hour window needs sustained throughput of about 120 GB/hour before headroom — a figure worth confirming against actual link capacity before the RPO is finalized, not after.

5. Establish Failover and Failback Procedures

Document exactly who declares a disaster, who has authority to trigger failover, and the technical runbook for bringing each system online at the secondary site — plus, just as important, the reverse process for failing back to the primary site once it is repaired. Failback is frequently left undocumented and becomes its own outage.

6. Test the Site on a Fixed Schedule

A DR site that has never been tested is a hypothesis, not a plan. Run tabletop exercises quarterly and a full failover drill at least once a year, escalating over time from isolated system tests to a full-scale simulated regional outage. ISO 22301 explicitly requires periodic testing and exercising as part of maintaining a certified business continuity management system.

7. Map Application Dependencies and Recovery Order

Recovery order is a design constraint, not something to settle during an incident. A system comes back only after everything it depends on has already come back — and the map that determines that order is rarely the same as the application inventory.

For each Tier-1 system, record its dependencies on database instances, middleware, message queues, API gateways, directory services such as Active Directory or LDAP, DNS, and third-party interfaces, noting the direction of each relationship. Use that map to settle, in advance rather than during an incident:

1. The start-up order for each tier, agreed with application owners rather than inferred from an architecture diagram.

2. Dependencies that must be running before an application can start, and those it can survive without.

3. Database consistency checks that must pass before a system is declared available, particularly where data was replicated while transactions were still in flight.

4. External interfaces owned by third parties, whose readiness is outside your control and should be tracked in the runbook.

8. Design the Network Cutover

Data arriving at the secondary site is not the same as users reaching it. Cutover spans components owned by different teams, so it should be designed and rehearsed in advance rather than improvised during an incident:

1. DNS records and time-to-live values: lower TTLs ahead of a planned cutover so records can be repointed quickly, and keep the previous records so the move can be reversed.

2. Site-to-site VPN or SD-WAN paths that terminate at the secondary site and do not rely on equipment sitting in the failed primary site.

3. Load balancer health checks and pool members, with a defined method for shifting traffic, whether by DNS or through a global load balancer.

4. Firewall rules, NAT, and IP address mappings required by the recovered systems, applied and tested before the incident rather than during it.

5. Routing validation confirming the secondary site can reach its dependencies and external services, since a system that cannot reach them is not recovered.

9. Build Ransomware-Resilient Recovery

Treat the recovery copy as a separate security domain rather than a mirror of production: the realistic failure mode is that replication carries the encrypted state to the secondary site before anyone detects the attack, leaving both locations with data that cannot be trusted. NIST SP 800-209 covers the storage-level controls this depends on; the practical recovery measures are set out in our guide to recovering virtual machines after ransomware.

10. Prove the Design Works With Real Numbers

A documented test schedule is not evidence that recovery works. Record actual RTO, actual RPO, data consistency, application availability, and failback success every time, then treat the gap between target and actual as the input to the next design revision. The full measurement set and step-by-step process are covered in testing restores without affecting production.

Site Selection Factors

• Geographic separation: place the secondary site outside the primary site's blast radius — typically a different power grid, weather system, and seismic zone, with 100+ miles of separation as a common baseline for regional risks.

• Independent infrastructure: power, internet, and telecom links should not share a single upstream provider or substation with the primary site.

• Data residency and regulation: some industries and jurisdictions restrict where regulated data can be replicated or stored.

• Staff accessibility: if the design assumes on-site personnel during a failover, the location needs realistic travel and lodging options during a regional emergency.

Cost Considerations

Three ownership models dominate secondary-site budgeting, each with a different cost curve:

• Self-built secondary data center: highest capital expenditure and longest lead time (often six figures or more before a server is installed), but maximum control — usually justified only for large enterprises with strict data-residency needs.

• Colocation: lower capital cost than building from scratch, typically priced per rack unit or per kW of power per month; the business still owns and manages the hardware and replication stack, but leases space, power, and cooling.

• Cloud DRaaS: lowest upfront cost and fastest to deploy, usually billed per protected VM or per GB replicated, but recurring costs scale with data volume and require careful egress-fee modeling.

Whichever model is chosen, budget for the full lifecycle cost — bandwidth, software licensing, and the labor hours spent on quarterly and annual testing — not just the initial hardware or subscription price. Underbudgeted testing is a common reason DR plans quietly go stale.

Common Mistakes to Avoid

• Treating backups as a disaster recovery plan — a backup alone cannot run the business; it only stores data.

• Skipping regular failover tests, so the plan is unproven when an actual disaster occurs.

• Placing the secondary site close enough to share the same regional risk as the primary site.

• Leaving the failback process undocumented, turning the return to normal operations into a second incident.

• Sizing replication bandwidth for average load instead of peak change rate.

• Assuming redundant copies will never fail together — the failure mode behind the rebuild described above.

Frequently Asked Questions

Q1: How far should a secondary DR site be from the primary site?

Far enough to avoid sharing the same power grid, weather event, or seismic zone — commonly 100 miles or more for regional risks, though the right distance depends on the specific hazards a business is planning against.

Q2: Can a cloud environment serve as a secondary DR site?

Yes. Cloud-based DRaaS is now a common alternative to owning or leasing physical infrastructure, offering warm-site economics with the option to scale up to hot-site performance during an actual failover.

Q3: Do businesses need one DR site for every system, or can requirements differ by system?

Requirements should differ by system. Tiering systems by criticality — and assigning each tier its own RTO and RPO — keeps the overall DR program affordable while still protecting the systems that matter most.

Q4: What does a secondary DR site typically cost?

It ranges widely by model: colocation is usually priced per rack unit or kW of power per month, cloud DRaaS is usually billed per protected system or per GB replicated, and a self-built site carries six-figure-or-higher upfront capital cost. The right comparison is total lifecycle cost — including bandwidth, licensing, and testing labor — against the hourly cost of the downtime the site is meant to prevent.

Design Checklist

• Business impact analysis completed, with RTO and RPO defined per system tier

• Site type (hot, warm, or cold) and deployment model selected to match those targets and budget

• Geographic and infrastructure risk assessment completed for the candidate site

• Replication method sized to peak change rate, with bandwidth confirmed

• Failover and failback runbooks documented and assigned to named owners

• Annual full failover test and quarterly tabletop exercises scheduled

• Compliance requirements, including standards such as ISO 22301, mapped to the plan

Your Next Step

Don't try to design the whole program in one sitting. Pick one Tier-1 system, run its business impact analysis, write down its RTO and RPO, and schedule one failover test for it this quarter. A single system tested end to end teaches more about where the real gaps are than a checklist covering everything on paper.