Glossary
What Is a Hot Site?
A hot site is a secondary data center that is fully equipped, continuously supplied with current data, and able to take over production workloads within minutes of the primary site becoming unavailable. Everything the workload needs is already in place and already running — hardware, software, network capacity, configuration, and a live copy of the data — so recovery means redirecting traffic rather than rebuilding an environment.
The term comes from contingency-planning practice, where alternate sites are graded by how much is standing before anything goes wrong. NIST’s Contingency Planning Guide describes a hot site as a facility sized for the system it supports and configured with the necessary hardware, supporting infrastructure, and personnel — one step below a mirrored site, which is identical to the primary in every technical respect, and several steps above a cold site, which offers only space, power, and connectivity.
The nuance worth carrying into any design discussion is that what makes a site hot is the state of its data, not the inventory of its equipment. The engineering problem is almost entirely a data-movement problem, and the constraint that shapes every decision in it is the distance between the two buildings.
What makes a site hot
Three conditions have to hold at the same time. Miss any one of them and what you have is something else with a hot site’s budget:
- Capacity is provisioned and running. Compute, storage, and network sized for the production load — powered on, patched, licensed, and monitored, not crated in a corner waiting for an emergency.
- Data is current. Replicated continuously, with a lag that is measured rather than assumed.
- The path to it is proven. Name resolution, load balancing, identity, certificates, and the failover procedure itself all work — demonstrated by test, not by diagram.
Two numbers govern the whole design. Recovery time objective (RTO) is how long the workload can be unavailable. Recovery point objective (RPO) is how much recent data you can afford to lose. A hot site is how you buy a low RTO; the replication design underneath it is what sets the RPO. They are bought separately, and treating them as one number is the most common error in site planning — a facility that can be running in five minutes is of limited comfort if it is running on data from last night.
Hot, warm, cold, and mirrored sites compared
Alternate sites are conventionally graded by how much is already in place before anything goes wrong. The categories are informal but widely used, and they map cleanly onto cost:
| Site type | What is in place | State of the data | Time to resume | Relative cost |
|---|---|---|---|---|
| Cold site | Space, power, cooling, and network connectivity. No equipment. | None on site | Days to weeks | Lowest |
| Warm site | Some or all of the hardware, software, and connectivity, installed but not carrying current state | Restored from backup, or refreshed periodically | Hours to days | Moderate |
| Hot site | Fully configured hardware, software, connectivity, and the staff to run it | Continuously replicated and current | Minutes to a few hours | High |
| Mirrored site | Identical to the primary site in all technical respects | Mirrored in real time | Effectively immediate | Highest |
The boundary that matters is between warm and hot, and it is a boundary about data rather than equipment. A rack of identical servers holding a two-day-old copy is not a hot site; it is a well-equipped warm site. Conversely, the distinction between hot and mirrored is one of degree — a mirrored site is a hot site with the replication lag driven to zero and the configuration drift driven out.
Active-passive and active-active
Hot sites run in one of two operating models, and the choice has more effect on real-world reliability than any hardware decision.
In an active-passive design, the second site receives replicated data and serves no production traffic until a failover is declared. It is simpler to reason about and cheaper to design, but its failover path is exercised only during tests — and any code path exercised twice a year should be assumed broken until proven otherwise.
In an active-active design, both sites serve production. A site failure removes capacity rather than triggering a procedure, so there is no cutover to get wrong. The cost is design complexity: something has to decide which site owns a given write, and what happens when the link between them drops while both are still serving clients. The compensation is that the failover path is in constant use, which is the most reliable form of testing there is. For object storage in particular, two sites each serving local applications and replicating to the other is a common enterprise pattern.
The replication decision underneath it
Every hot site rests on a choice between synchronous and asynchronous replication, and that choice is constrained by physics rather than by product features.
Synchronous replication acknowledges a write to the application only once it is committed at both sites. RPO is zero — nothing acknowledged is ever unprotected — but every write now includes a round trip across the link. Light travels through fibre at roughly 200,000 km/s, so about every 100 km of fibre path adds a millisecond of round-trip time, and real routes are always longer than the distance on a map. That is why synchronous designs are metro-range in practice, and why vendors publish a latency ceiling and a bandwidth floor rather than a distance in kilometres.
Asynchronous replication acknowledges the write locally and propagates it afterwards. Primary-site latency is unaffected and distance becomes a commercial question rather than a physical one, but there is now a window — usually seconds, sometimes minutes under load — in which the most recent writes exist at one site only.
| Aspect | Synchronous | Asynchronous |
|---|---|---|
| RPO | Zero | Seconds to minutes, depending on link and change rate |
| Distance | Bounded by latency — typically metro range | Effectively unbounded |
| Effect on primary writes | Each write carries the round trip to the second site | None |
| Behaviour when the link degrades | Writes stall unless the design degrades gracefully | Both sites keep serving; a replication queue builds |
| Best suited to | Zero-data-loss requirements within a metro area | Cross-region protection and regulatory distance requirements |
There is also a structural choice that often gets conflated with this one: whether the two sites are one logical system spanning both buildings, or two independent systems replicating between them. A single stretched system has nothing to fail over — losing a site is a degraded state, not an event — but the latency limit is hard and non-negotiable. Two independent systems can sit on different continents, but failover becomes a procedure with a runbook, a decision-maker, and a reverse direction that also has to work.
What a hot site does not protect against
A hot site is insurance against losing a facility. Several common failure modes sit outside that policy, and each has cost organizations more than the outage they were preparing for.
- Correlated failure. Two sites on the same flood plain, the same power grid, or the same regional carrier fail together. Contingency-planning guidance is explicit that a fixed alternate site should be geographically distant from the primary — which pulls directly against the latency limit on synchronous replication. That tension is the central design problem, not a detail to be resolved later.
- Logical corruption. Replication is indifferent to whether what it is copying is correct. Ransomware encryption, a bad migration, an errant bulk delete — all of it reaches the hot site as fast as the link allows, and a lower RPO propagates the damage faster. Surviving this requires immutable, versioned copies: object lock with a retention period the storage layer actually enforces, rather than an API that accepts the call and lets a sufficiently privileged administrator remove the lock.
- A shared control plane. If both sites authenticate against the same directory, resolve names through the same DNS, or depend on the same license server or certificate authority, that shared dependency is the real single point of failure — and it is usually what turns a five-minute RTO into a four-hour one.
- Capacity and configuration drift. The hot site was sized for the load of the year it was built and configured to match a primary that has since changed. Drift is silent, accumulates continuously, and is only visible during a test.
Stated plainly: a hot site is a facility strategy and a backup is a data strategy. Substituting one for the other is a well-documented way to survive a fire and still lose the data.
What a hot site costs
Duplicate capacity is the obvious line item and rarely the one that breaks a budget. The ones that do are less visible: wide-area bandwidth sized for peak change rate rather than average, duplicated software licensing, the staff and processes to operate a second production environment, and the storage overhead of whatever protection scheme spans the sites.
That last item varies more than most planning assumes. Replicating a full copy to a second independent system costs 100 percent of the data footprint on top of whatever local protection each site already carries. Erasure coding a single logical system across three sites can land materially lower — Scality documents roughly 75 percent overhead for a three-site stretched RING, against 100 percent for the second copy plus local protection overhead at each site in a two-system replicated design. At petabyte scale, the difference between those two numbers is a procurement decision in its own right.
Testing is the remaining cost, and it is the line most often quietly cut. An untested hot site is an expensive assumption.
How to tell whether a hot site actually works
The only useful evidence is a failover nobody rehearsed. A practical sequence:
- Fail over unannounced, during business hours. A scheduled Sunday-night test validates the runbook under the one set of conditions that will not apply when it matters.
- Fail back. Returning to the primary is the half of the exercise people skip, and it is usually the harder half — resynchronising a site that drifted while it was down.
- Measure the actual RPO rather than quoting the target. Replication lag under peak write load, not the average across a quiet week.
- Test at production data volume. Behaviour at ten terabytes tells you very little about behaviour at ten petabytes, particularly for metadata and object listing operations.
- Inventory the cross-site dependencies. DNS records and their TTLs, identity providers, certificates, license servers, and any third-party service that calls back to a primary-site address.
- Verify immutability separately. Set a retention period, then attempt to delete the object as an administrator. If it succeeds, the retention is decorative and the hot site is not a ransomware control.
- Time the people, not just the systems. RTO starts when the incident starts, and it includes the time taken to notice, escalate, and decide to declare a disaster. That interval is frequently longer than the technical cutover it precedes.
Hot sites and the storage layer
Because the hard part of a hot site is keeping the data current, the capabilities of the storage platform tend to determine which site strategies are available at all. Both patterns discussed above exist in practice: a synchronous, stretched deployment spanning sites within a metro area, and asynchronous replication between independent systems at arbitrary distance.
Scality’s platforms cover both. RING and ARTESCA approach the problem from different ends. RING can be deployed as a synchronous stretched cluster across two or three sites — Scality documents 10 Gb/s or greater bandwidth and under 5 ms of wide-area latency for that configuration, and a three-site stretched RING tolerates the loss of an entire site plus an additional server or disk group with zero RPO and RTO. For distances beyond that limit, independent RINGs replicate asynchronously; one production deployment runs two active sites more than 1,200 miles apart at 80 PB with a sub-60-second RPO. ARTESCA, the backup-focused platform, replicates asynchronously and event-driven to another ARTESCA or RING instance or to public cloud, with S3 object lock providing the immutable copy that replication alone cannot.
The honest framing when evaluating any vendor here is that zero RPO and RTO is a property of synchronous configurations inside their documented latency envelope. A design spanning continents is asynchronous by necessity, and its RPO is a number to be measured under load rather than a claim to be accepted.