Standing up a recovery site involves the same work as building any data center presence — space, power, cooling, network, racks, equipment, connectivity. What makes it a different problem is that the environment has to remain equivalent to production indefinitely, while nobody uses it day to day.
That maintenance problem, not the construction, is what determines whether the site is useful when it is needed. Most recovery sites are built adequately and then allowed to drift.
Which Recovery Tier Are You Building?
Cold, warm, or hot, chosen from the recovery targets, which have to be settled first because they determine everything downstream. The tiers below follow the cold, warm, and hot site definitions in NIST SP 800-34.
Cold provides space, power, and connectivity with no equipment standing by. Cheapest to hold, longest to activate — equipment must be procured or shipped, installed, and configured before recovery begins. Appropriate where the tolerable outage is measured in days or longer.
Warm holds equipment installed and configured, with data replicated on some interval. Activation means bringing systems up and applying the most recent data. Recovery in hours, at the cost of maintaining an idle environment.
Hot runs equivalent capacity with current data, capable of taking production quickly or immediately. Most expensive and the only tier that satisfies very short recovery targets.
Different systems can sit at different tiers in the same facility, and usually should. Building everything to the tier the most critical system requires is a common and expensive default.
Where Should a Recovery Site Be?
Far enough from the primary site that one event cannot hit both, and close enough for the replication approach. Separation distance is driven by the threat model and bounded by replication: synchronous replication imposes a latency ceiling that translates directly into a distance ceiling.
Beyond distance, evaluate independence rather than mileage: a different utility grid segment, a different flood plain (check the FEMA flood maps) and seismic zone, carrier diversity with documented physical route separation, and a location that remains reachable when the primary region is disrupted.
Consider access practically. Staff have to get there during an event, which means proximity to transport that works when regional conditions are poor. A site reachable only by a route that floods is a site with a conditional recovery plan.
Match the Environment, Not Just the Capacity
The recovery environment has to be equivalent enough that production actually runs on it.
Equivalence means matching architecture, not merely capacity: the same processor generation where licensing or application compatibility depends on it, the same storage capabilities and performance characteristics, the same network topology and address design, and the same security posture — firewall rules, access control, and monitoring.
The security point is underweighted. Recovery sites are frequently built with lighter controls on the reasoning that they hold no production load, and then they take production load during the worst week the organization has had. The controls need to be equivalent because the data will be.
Underprovisioning deliberately is legitimate if the reduced capacity is documented and the business has accepted it. Recovering at sixty percent capacity is a decision. Discovering during an incident that you are at sixty percent is a failure.
How Much Bandwidth Does Replication Need?
Enough for the peak change rate, not the average. Scheduled data copy jobs, batch processing, and period-end closes produce bursts that a link sized to the average cannot absorb, and a replication stream that falls behind during peak has a recovery point that degrades exactly when it is most likely to be tested.
Account for the initial seed. Replicating an established environment from zero over the wire can take weeks. Physical seeding — shipping a copy and starting replication from there — is standard practice and needs to be planned rather than discovered.
Monitor replication health with alerting that reaches someone. Silent replication failure is the most common way a recovery site becomes useless, because everything looks fine until the day it matters.
Keeping It Current
This is the part that fails, and it fails gradually.
Production changes constantly — patches, configuration, new applications, new dependencies, capacity growth. Every change that does not reach the recovery site widens the gap between the two, and no single change is large enough to notice.
Build the recovery site into change management as a required consideration rather than an optional one. Every production change should have an explicit answer for whether it applies at the recovery site, even when the answer is no.
Idle equipment degrades on its own. Firmware drifts out of alignment, certificates expire, licenses lapse, and disks fail unattended. Power the environment periodically, patch it, and verify it. Equipment that has not been powered in a year is equipment of unknown status.
Reconcile the two environments on a schedule — an actual comparison of configuration, versions, and capacity, producing a list of differences to remediate. Annual is a minimum; quarterly is better for environments that change quickly.
Prove It Works
A recovery site that has never run production is a hypothesis.
Test at increasing levels of realism: component recovery, then application recovery, then full failover with real users doing real work. The last one is disruptive and it is the only test that answers the question.
Test the logistics alongside the technology — staff access, out-of-band communications, the declaration decision, and remote hands response. Those layers fail independently of the equipment and are rarely exercised.
Document what failed and fix it. A test that surfaces problems has done its job; a test that surfaces problems which are still present at the next test has not.