What is a warm site?
A warm site is an alternate processing location that sits between a hot site and a cold site. The racks, servers, storage and network circuits are installed, and operating systems and some applications may already be loaded, but production data is not kept current. To bring it online after a disaster, the team restores the most recent backups, applies configuration, starts services and checks that everything works. That usually takes hours to a few days. A warm site costs less than a hot site because nothing is replicating or running at full scale, and it recovers much faster than a cold site because nothing has to be bought or shipped.
What a warm site recovery involves
- A named person with the authority to do so declares a disaster, which activates the plan and the site contract.
- Network connectivity, firewalls and remote access for the recovery team come up first.
- Core services follow in dependency order: DNS, DHCP and time synchronization, then identity such as Active Directory.
- Databases and file data are restored from the latest backups, which may first have to be recalled from offsite storage or downloaded from the cloud.
- Application servers and front ends start, and business users confirm that functions and data are correct before service is declared restored.
Every step after the declaration uses up recovery time, so a warm site's real speed depends on how fast the backups can be restored. Restoring 40 TB over a 10 Gbps link takes about 9 hours even at full line rate, and real throughput is lower.
Warm sites in the cloud
Cloud recovery patterns map onto the same scale. In a pilot light design, a few core pieces, such as a database replica, run all the time while the rest of the environment is launched on demand from stored images and infrastructure-as-code templates. In a warm standby, a scaled-down but complete copy of production runs continuously and is scaled up during failover. Both sit between a cold rebuild and a full hot site in cost and speed. Keep the recovery copies and their admin credentials in a separate account, so an attacker who controls production cannot delete the recovery environment too.
Example: choosing a warm site
A regional insurer's business impact analysis gives its claims system a recovery time objective (RTO) of 24 hours and a recovery point objective (RPO) of 4 hours. A hot site would meet both targets but costs far more than the business wants to spend on a system that can be down for a day. A cold site could take a week or more to equip. A warm site with servers already racked, plus backups every two hours copied offsite, meets both: the restored data is never more than about two hours old, and a tested restore that finishes in about ten hours fits inside the 24-hour RTO.
Warm site vs. hot site vs. cold site
- Hot site: fully running with current data; minutes to hours; highest cost.
- Warm site: hardware ready, data must be restored; hours to days; moderate cost.
- Cold site: space, power, cooling and connectivity only; days to weeks; lowest cost.
One way to remember the scale: a hot site is already running, a warm site has its equipment waiting, and a cold site has only the building. These are typical descriptions rather than standard definitions, and a well-tested warm site can beat a neglected hot site.
Warm site on the CompTIA Security+ exam
Recovery sites fall under SY0-801 objective 3.4, which covers why systems must be designed to survive failures and recover from them. Wording such as "balance cost and recovery time", "equipment is in place but data must be restored" or "can be offline for up to a day or two" points to a warm site. A hot site is the tempting distractor when it would also meet the time limit, but if the question asks for the most cost-effective option, pick the cheapest site whose recovery time still fits. A cold site is wrong when the tolerance is shorter than the days or weeks needed to obtain and configure hardware.