Hot site vs warm site vs cold site: what each DR site has in place and where DRaaS fits

Hot, warm and cold sites: what each one has in place

A cold site has space, power, cooling and network connections but no computer equipment. A warm site holds some or all of the hardware and telecommunications, while systems and data still have to be brought up to date. A hot site is sized for the systems it protects and equipped with hardware, infrastructure and staff, so systems start there with little setup. How much is in place before a disaster sets both the recovery time and the cost of keeping the site ready.

The definitions used here are from section 3.4.3 of NIST Special Publication 800-34 Revision 1, the Contingency Planning Guide for Federal Information Systems (updated 11 November 2010, current in October 2026). NIST sorts alternate sites by “operational readiness”. Cold sites are typically facilities “with adequate space and infrastructure (electric power, telecommunications connections, and environmental controls) to support information system recovery activities”. Warm sites are “partially equipped office spaces that contain some or all of the system hardware, software, telecommunications, and power sources”. Hot sites are “appropriately sized to support system requirements and configured with the necessary system hardware, supporting infrastructure, and support personnel”. As variations, NIST adds mobile sites, “self-contained, transportable shells”, and mirrored sites, “fully redundant facilities with automated real-time information mirroring”.

NIST SP 800-34 Rev. 1, section 3.4.3 and its sample alternate site criteria (cold, warm and hot rows; mobile and mirrored sites from the text). The explanations after each setup rating and the effort column are our summary.

Vendors use the same words for different states. AWS’s disaster recovery whitepaper (last revised 1 April 2022) uses warm standby for “a scaled down, but fully functional, copy of your production environment” that is already running, and hot standby for an active/passive set-up in which “DR regions do not take traffic”. A warm offer can therefore mean idle hardware or servers running at reduced scale, so compare offers by what is installed, how current the data is and what is left to do after a disaster is declared.

Cold site: space and power, recovery from backups

With a cold site, recovery begins with building the platform. NIST notes that cold sites “are the least expensive to maintain, although they may require substantial time to acquire and install necessary equipment”. Section 3.4.4 of the guide names three ways to get the hardware: vendor agreements, where “The SLA should specify how quickly the vendor must respond after being notified” and what priority you get in a disaster “involving multiple vendor clients”; equipment bought in advance and stored off site; and compatible equipment used elsewhere in the organisation. Hypervisors, storage and the backup infrastructure come next, and only then the restore from off-site copies, directory service and DNS first, at the rate the slowest link in the path allows; our article on why backup is not disaster recovery works through that arithmetic.

Warm site disaster recovery: partly equipped, partly current

A warm site sits in the middle of NIST’s range, with hardware rated “Partial”, telecommunications “Partial/Full” and setup time “Medium” in its sample alternate site criteria. For a virtualised estate, it can be a smaller cluster or older hosts in another building or a colocation rack, with storage that receives backup copies or periodic replicas and a WAN link that is already up. Data already on the site’s storage can be restored or started locally, while data held only on tape or in a cloud archive has to be transferred first. Hosts that carry only part of the production load need a start list agreed beforehand. Configuration drift adds time, because hypervisor versions, network settings and firewall rules that changed in production since the last test must be reconciled at the warm site; NIST asks for a related check when a site is chosen, so that the system’s “security, management, operational, and technical controls are compatible with the prospective site”.

Hot site disaster recovery and mirrored sites

NIST rates a hot site’s hardware and telecommunications “Full” and its setup time “Short”. Its definition does not cover data, whose age depends on how copies reach the site, and Table 3-2 pairs the hot site with “Mirrored systems and disc replication” for mission-critical systems. With replicated data and hardware in place, the start order and the redirection of users and network traffic decide most of the recovery time.

A mirrored site is “identical to the primary site in all technical respects”. Mirroring copies every write, corrupted and encrypted ones included, and AWS notes for multi-site active/active that “data corruption may need to rely on backups, which usually results in a non-zero recovery point”. Synchronous mirroring also limits the distance between the sites. Our disaster recovery page places active-active synchronous clustering where an hour of downtime is already too much, and notes that it doubles infrastructure and budget.

Mobile sites and reciprocal agreements

A mobile site arrives as a transportable shell “custom-fitted with specific telecommunications and system equipment”. According to NIST, “In many cases, mobile sites may be delivered to the desired location within 24 hours”, and installation and setup add to that time; the place it goes still needs power and network connections.

A reciprocal agreement shares the cost with another organisation: “Two or more organizations with similar or identical system configurations and backup technologies may enter into a formal agreement to serve as alternate sites for each other”. NIST warns that “each site must be able to support the other, in addition to its own workload, in the event of a disaster”, that both sides must agree the recovery order jointly, and that tests should cover headroom, compatible configurations, security measures and “the sensitivity of data that might be accessible by other privileged users”. The partner may be internal, so the same applies to two data centres of one company that replicate to each other.

What drives the cost of each site type

The mirrored site is, in NIST’s words, “the most expensive choice”, while partially equipped sites such as warm sites “fall in the middle of the spectrum”, above cold sites. NIST’s budget planning template splits the cost of a cold, warm or hot site into vendor, hardware, software, travel and shipping, labour or contractor, testing and supply costs.

Hardware kept for recovery is the most visible item at warm, hot and mirrored sites, with maintenance contracts and a refresh cycle of its own. Standby systems need software licences on whatever terms each vendor sets for standby or DR use. The data link is sized for a nightly transfer with backup copies, for the rate of change with replication, and for low latency as well with synchronous mirroring. Staff keep the recovery site in step with production, since a change made only at the primary site can turn up as a failed start at failover. A commercial site adds what NIST lists as a “Cost/fee structure for disaster declaration and occupancy (daily usage)”, plus administration, maintenance and testing fees. Our disaster recovery page sums up the own-site case: “Your own standby site means doubling hardware, licences and people.”

Where DRaaS fits among the site types

Disaster recovery as a service is a commercially leased site, NIST’s third route besides a site of your own and a reciprocal agreement. In a replication-based service the provider runs the facility, the network and the compute capacity, and your virtual machines arrive as replicas, which Veeam’s Quick Start Guide describes as exact copies in native vSphere format “in the ready-to-start state”; our guide to Veeam replication, backup copy and Cloud Connect explains how they are kept current. In our reading, such a site sits between warm and hot. Where the contract reserves capacity for you, it matches NIST’s hot-site ratings of full hardware and telecommunications and a short setup time, while its data is as current as the last replication run and systems stay powered off until failover.

Approaches and typical figures from the comparison on our disaster recovery page; NIST types from SP 800-34 Rev. 1, Table 3-2 and section 3.4.3. The mapping is our reading.

How close a DRaaS site comes to a hot site in a disaster depends largely on the contract. NIST’s list of what an alternate-site agreement should address covers most of it: how a disaster is declared, priority access, other clients subscribing to the same resources, and testing time. For a commercial site, NIST also wants “recovery days (how long the organization can occupy the space during the recovery period)” in the contract. It warns that a shared site “may be unable to accommodate all of the customers if a disaster affects enough of those customers simultaneously”. Our DRaaS checklist turns these into questions to ask before you sign.

Our disaster recovery service is a site of this kind: your systems come up from replicas in Baltneta’s Tier-3 data centres in Lithuania and run while your primary site is down. Tell us which systems need it and how you recover them today.

Choosing a site type for each tier of systems

NIST’s Table 3-2 gives examples that match site types to impact: relocation or a cold site for low-impact systems, a cold or warm site for moderate ones, and a hot site for mission-critical systems. For every moderate- or high-impact system, the plan “should include a strategy to recover and perform system operations at an alternate facility for an extended period”.

1. Tier the systems by the consequences of downtime and data loss, as our guide to setting RPO and RTO per system describes.
2. Compare each tier’s RTO with the time a cold site needs to obtain hardware and restore data; if that is too long, the tier needs hardware waiting at a warm, hot or DRaaS site.
3. Compare its RPO with how often data leaves the primary site: daily backup copies suit a cold or warm site, replication a warm site, a hot site or DRaaS, and synchronous mirroring an RPO near zero.
4. Choose a location “unlikely to be negatively affected by the same hazard” as the primary site, in NIST’s words; our article on DR site distance covers how far that is.
5. Write down what each site lacks on the day and who supplies it, then test the recovery against the targets.

For the entities listed in its Article 1, Implementing Regulation (EU) 2024/2690 point 4.2.4 requires “at least partial redundancy” of network and information systems, facilities, equipment, personnel and communication channels, without naming a site type. Whether a company falls under it is a legal assessment for its legal department.

In our DR strategy design, we define together with you the critical systems and the target RPO and RTO for each tier. Describe your tiers in the form below, with the site each one would recover to today.

What we do

Our disaster recovery service gives critical systems a recovery site without a second data centre of your own: capacity in Baltneta’s Tier-3 data centres in Lithuania (ISO 27001, PCI DSS), geographically separate from your primary infrastructure, with EU data residency. Our engineering partner Vixen.UNO sets up virtual-machine replication from a 15-minute interval via Veeam Cloud Connect, managed from your Veeam console or entirely on our side, and runs scheduled failover tests in an isolated environment, with a report after each. The standard targets are an RPO from 15 minutes and an RTO of 1 to 2 hours for critical systems, and your targets per tier are fixed in the SLA. Where a system needs zero RPO, that is active-active synchronous clustering, a different class of solution, and we say so on the first call. Site, replication, tests and support come on one EU contract and invoice with Eurokommerz.

FAQ