Glossary
Warm Site
A warm site is a backup data center that already has hardware installed and a copy of your data, but is not running your production workload. If your primary site fails, you finish configuring it and bring systems live there — typically in hours to a couple of days.
It is the middle option between a cold site, which is an empty room, and a hot site, which is already running.
What is installed at a warm site
The building basics, same as a cold site: floor space, conditioned power, cooling, physical security and network connectivity.
On top of that:
- Servers and storage, racked and powered on. Usually not the full size of production — commonly enough to run business-critical systems rather than everything.
- Operating systems and base software installed and licensed, though often behind production's current patch level.
- Network configuration — circuits, VLANs, firewall rules and load balancer configs, frequently pre-staged.
- A copy of your data, refreshed either on a schedule or continuously.
What is typically not there: full production capacity, current application configuration, live user traffic, and up-to-the-second data.
How the data gets there
This choice affects your recovery more than any other decision in the design.
Restore from backup. Backup copies are sent to the warm site — over the network or on shipped media — and restored onto the standby hardware when you activate. It is the cheaper option and needs no special storage capability.
The trade-off is time in two places. Your data is as old as the last backup, usually up to 24 hours. And the restore itself takes real time: 100 TB read back at 1 GB/s is roughly 28 hours, which happens after you have declared the disaster.
Continuous replication. Data is copied to the warm site as it is written. Asynchronous replication acknowledges the write locally and ships it a moment later, so the second site trails by seconds or minutes. Synchronous replication commits at both sites before acknowledging, so nothing is lost — but every write waits for the round trip, which limits how far apart the sites can be.
Replication costs more in bandwidth and requires a storage platform that supports it, but it removes the restore step entirely and shrinks data loss from a day to minutes.
What happens during a failover
The gap between hardware being present and systems being usable is where warm site recovery time actually goes.
Missing capacity has to be filled — if the standby is sized at 60% of production, either extra hardware is sourced or lower-priority systems stay down. The platform is brought up to production's current state: patches, application versions, configuration changes made since the site was last synchronised. If the site holds backups rather than replicas, data is restored, which is usually the single longest step. Databases are recovered and checked for consistency. Finally, traffic is redirected — DNS records updated and propagated, certificates confirmed valid for the new location, and identity and authentication pointed at the surviving site.
Some of that can run in parallel. The data restore normally cannot, because everything else waits on it.
What to expect from each tier
| Option | Time to resume (RTO) | Data loss (RPO) | Relative cost |
|---|---|---|---|
| Cold site | Days to weeks | Whatever the last backup holds | Lowest |
| Warm site, restoring from backup | 1–3 days | Up to 24 hours | Low to moderate |
| Warm site, continuously replicated | Hours | Seconds to minutes | Moderate |
| Hot site | Minutes | Seconds to zero | Highest |
The two warm site rows are the same tier and the same label. The difference between them is one design decision about how data arrives.
What it costs
You are paying for hardware that produces nothing most of the time, plus the building costs that come with it — rent, power and cooling run whether or not the site is doing anything.
Two costs are commonly underestimated.
Keeping it in step. Production changes weekly. Every patch, configuration change and application release that does not reach the standby widens the gap you will have to close during an outage. This is ongoing operational work, not a one-off setup task.
Testing. A warm site that has never been failed over is an assumption. Real tests take the site down for the duration and need people available, which is why they are scheduled infrequently and are the first thing dropped when the team is busy.
The offset is that warm site hardware does not have to sit idle. Many organisations run development, test, reporting or backup workloads on it, and accept that those get evicted when the site is needed for real.
Who chooses a warm site
Organisations that can tolerate being down for a day but not a week, and cannot justify paying twice for infrastructure. That commonly means mid-sized enterprises, and departmental or second-tier systems inside larger ones where the top-tier applications get a hot site and everything else gets a warm one.
How Scality keeps a second site current
Scality RING supports both replication modes. Synchronous stretched configurations commit each write at both sites before acknowledging it, which gives no data loss; Scality's engineering guidance puts the practical envelope at 10 Gb/s or better and under 5 ms of latency between sites. Beyond that distance, replication is asynchronous, which always leaves some window of recent writes that have not yet arrived.
Scality ARTESCA replicates asynchronously between two sites, with objects appearing at the destination shortly after they are written at the source.
Both platforms support S3 Object Lock in governance and compliance modes. That matters here because replication copies everything faithfully, including ransomware encryption and accidental deletions — so a replicated warm site does not remove the need for retained, immutable backup copies.