A hot site is a standby facility running current equipment and data, ready to carry production load within minutes to hours. A warm site has equipment installed but must bring data current first, so recovery takes hours to days. A cold site offers only space, power, cooling and network capability, and recovery takes weeks.
Recovery time objectives are set in a policy document; standby infrastructure is funded in a budget cycle, months apart. The gap between them is where most disaster recovery programs fail. The question is not which tier is best but whether the posture you pay for can deliver the recovery you promised.
What is a hot site, a warm site and a cold site?
Each tier is defined by what is physically installed and running, not by the marketing term. NIST's contingency planning guide, SP 800-34, uses the same vocabulary.
Cold site: space, power, cooling and network capability, with no equipment installed. Recovery means procuring or transporting hardware, installing it and restoring data. Realistic recovery is measured in weeks.
Warm site: equipment racked, powered and configured, with data replicated periodically or restored from stored copies at recovery time. Recovery means bringing systems current and starting services. Realistic recovery is hours to days.
Hot site: fully configured equipment running current data through continuous or near-continuous replication, sized to carry production load. Recovery means failing over. Realistic recovery is minutes to hours.
Active-active: both sites carry production traffic continuously. There is no failover event, only capacity reduction. It is the most expensive posture, and the only one continuously proving it works.
How do hot, warm and cold sites compare?
The tiers trade cost against recovery time. Read the recovery row as a ceiling, not a promise: each figure assumes the standby site actually matches production.
| Cold site | Warm site | Hot site | Active-active | |
|---|---|---|---|---|
| Equipment | None installed | Racked, configured | Production-sized, running | Carrying production |
| Data | Restored after the event | Periodic replication | Near-continuous replication | Live at both sites |
| Recovery means | Procure, install, restore | Bring current, start services | Fail over | Absorb lost capacity |
| Realistic recovery | Weeks | Hours to days | Minutes to hours | No failover event |
| Relative cost | Lowest | Moderate | High | Highest |
Most organizations run more than one tier at once: hot standby for the handful of systems with the tightest recovery targets, warm or cold for everything else. The next section explains how to decide which is which.
Should you tier by site or by application?
Tier by application. Whole-site tiering overspends on unimportant systems and underspends on critical ones; most environments have a small set of applications that genuinely need hot standby and a long tail that does not.
Use two numbers per system: the recovery time objective (RTO), how long the business can function without it, and the recovery point objective (RPO), how much data loss is acceptable. Both must come from the business and be tested against reality. Stated RTOs are systematically optimistic, because stating a short one costs nothing at the time. Ask what the business actually did during the last unplanned outage.
RPO drives replication design more than RTO does. An RPO of zero requires synchronous replication, which imposes a distance limit; an RPO of a few hours permits asynchronous replication and wider geography. Those are your IT team's design decisions. The physical side is in recovery time objectives and physical logistics.
What does standby infrastructure really cost?
The standby hardware is the visible cost and rarely the largest one. The costs people miss:
- Software licensing at the recovery site, which many vendors charge for even when passive
- Replication bandwidth, sized for peak change rate rather than average
- Refresh cycles at both sites simultaneously, since standby equipment ages at the same rate
- Staff time to maintain configuration parity, which is continuous rather than periodic
- Facility contracts, cross-connects and carrier circuits
- Testing, including the outage windows testing consumes
Budgeting the hardware and forgetting the maintenance produces a hot site that degrades into a warm site over two or three years without any decision being made. Compare tiers on the full annual cost of holding each one at its stated recovery time, not on equipment price.
Why does a hot site quietly become a warm site?
Configuration drift. A hot site is only hot if it matches production, and every change made at production but not at standby widens the gap:
- Firewall rules added during an incident and never replicated
- Patches applied on different schedules
- Application configuration changed by hand rather than through deployment tooling
- Certificates renewed at production only
- Capacity added at production while standby stays at its original sizing
Configuration management and infrastructure-as-code are the practical defense, because they make parity a property of the deployment process rather than a task someone remembers. Where standby is maintained manually, drift is a certainty; the only variable is how much has accumulated. Capacity drift matters most: production grows continuously, standby is sized once, and a hot site provisioned three years ago may be unable to carry today's load.
How far apart should primary and recovery sites be?
Far enough not to share a disaster, close enough for the replication your RPO requires.
Too close, and the sites share risk: the same power grid, flood plain, metropolitan fiber routes or regional weather event. Correlated risk is invisible in normal operation, so check both addresses on the FEMA Flood Map Service Center before signing a facility contract.
Too far, and synchronous replication becomes impossible. Round-trip latency imposes a practical limit, typically in the range of tens of kilometers before write performance degrades noticeably. Beyond that, asynchronous replication and a non-zero RPO are the only options.
Evaluate shared dependencies explicitly: power utility and substation, water supply, carrier physical routes, regional hazard exposure, and whether staff can reach both sites during a regional event. See geographic redundancy and site separation distance.
What physical upkeep does a standby site need?
The same discipline as production, because recovery facilities are visited rarely and degrade quietly. Typical findings at a neglected site:
- Badge and access lists that were accurate two years ago
- Spares consumed at production and never replenished at standby
- Remote-hands arrangements that were never exercised
- Documentation describing a rack layout that has since changed
- Equipment deliveries and installations done without the rigor applied at the primary site
Put standby site changes under the same change control as production. Informal work at a site nobody watches is exactly what makes it unreliable when it matters. If you are standing up a cold or warm site from an empty room, plan delivery, racking, cabling and labeling as a project in its own right; see building a disaster recovery site from nothing.
How do you prove a recovery tier actually works?
Test it at the tier you claim. A tier you have not tested is a tier you do not have: a hot site that has never carried production traffic is an assertion, while a warm site with a documented, timed, recently executed recovery is a capability.
Run full failover for hot standby, timed restoration for warm, and at least a realistic procurement and installation estimate for cold, including equipment lead times and transport. Time every step. Then compare the measured result against the RTO in the policy document, and correct whichever of the two is wrong. Ready.gov's business continuity guidance frames the same loop: plan, test, revise. For what makes an exercise realistic rather than ceremonial, see realistic disaster recovery testing.