Recovery Strategies

A hot site for a process whose downtime tolerance is a week is over-engineered waste, which is why the exam's correct recovery strategy is almost always the cheapest option that still meets the requirement, not the fastest one available. The requirement arrives as two numbers from earlier planning: the Recovery Time Objective (RTO), the maximum tolerable time a process can be down, and the Recovery Point Objective (RPO), the maximum tolerable data loss. A recovery strategy is money committed in advance to satisfy them, and this section optimizes that cost-versus-RTO trade.

A recovery strategy is pre-positioned capability, sized to requirements you were handed

A recovery strategy is the alternate site, the backup regime, and the resilient infrastructure you fund before a disruption so that, when one arrives, recovery completes inside the RTO and loses no more data than the RPO permits. The requirements engine sits upstream: the Business Impact Analysis (BIA) ranks processes by criticality and derives MTD, RTO, and RPO (covered in business-continuity). This subtopic does not re-derive those numbers; it spends against them. Keep that division straight, because a common exam distractor answers a strategy question by re-running the BIA, which is the wrong layer.

The cost-balance point: the single trade that governs every choice here

NIST SP 800-34 Rev. 1 frames the economics as two opposing curves: "the cost for disruption" rises the longer an outage runs, while "the cost to recover" rises as the recovery time shortens (NIST SP 800-34 Rev. 1, §3.2.1^[1]). Where the two curves cross is the cost-balance point, and the RTO that sits there is the optimum. NIST is explicit about the two ends of the spectrum: "a short RTO (system recovery within minutes)" typically requires expensive options such as "system mirroring and alternate site facilities," whereas "a longer RTO ... can be accomplished by less expensive solutions such as tape backup" (NIST SP 800-34 Rev. 1, §3.2.1^[1]). This is why the CISSP-correct strategy is the least expensive solution that still satisfies the requirement: a hot site for a process whose MTD is a week is over-engineered waste, and a tape-only strategy for a process needing minutes of RTO is negligent under-provisioning.

Two dimensions, two controls

Throughout this page, hold two dimensions separate because two different controls serve them. Time-to-recover is served by the recovery site (cold/warm/hot/mobile/cloud): that is the RTO dimension. Data-loss tolerance is served by the backup and replication regime: that is the RPO dimension. A team can over-invest in one and forget the other; the durable design names both targets first, then picks a site to meet the RTO and a backup cadence to meet the RPO. The figure below holds those two dimensions side by side: each is served by a different control, so name both targets before choosing either.

This section covers the alternate-site decision, the most heavily tested part of recovery strategy. Read the cost-balance idea above first; every site type is a different point on that curve. The mechanics here are which equipment each type pre-stages and, therefore, how long activation takes.

One spectrum, defined by how much you pre-stage

All four classic site types answer one question (how much do you install and keep current in advance?) and the answer fixes both cost and activation time. NIST SP 800-34 Rev. 1 defines the canonical types (NIST SP 800-34 Rev. 1, §3.4.2^[1]):

• Cold site: environmental support only: "adequate space and infrastructure (electric power, telecommunications connections, and environmental controls)" but no IT equipment and no current data. Cheapest to retain, but activation is measured in weeks because you must procure, install, configure, and load data before it can run; a cold site is therefore paired with offsite backups to supply that data on activation.
• Warm site: "partially equipped office spaces that contain some or all of the system hardware, software, telecommunications, and power sources." Hardware is staged but data must be restored from backups, so activation runs hours to days at moderate standing cost.
• Hot site: "office spaces appropriately sized to support system requirements and configured with the necessary system hardware, supporting infrastructure, and support personnel." Kept continuously synchronized with production data, so it takes over in minutes to hours, the fastest and the most expensive.
• Mobile site: "self-contained, transportable shells custom-fitted with ... telecommunications and IT equipment" delivered to a chosen location. The right tool when the building itself is unusable, the site must be relocated, or the location is remote; activation depends on transport and connection time.

The ordering to memorize cold: cost and recovery-speed both increase cold → warm → hot, and they move together (faster always costs more).

Cloud and DRaaS: the modern point on the same curve

Cloud recovery, including Disaster-Recovery-as-a-Service (DRaaS), is not a fifth philosophy; it is the same spectrum delivered as pay-per-use capacity. Because compute is provisioned on demand, a cloud strategy can behave like a warm or hot site (replicate continuously for near-zero RTO, or hold images and spin up on failover for a longer RTO) while paying mostly for storage until the disaster, when full compute is invoked. Cloud also delivers geographic separation by default through provider regions/zones. For example, AWS describes Availability Zones as "multiple, isolated locations" within a Region and notes that launching across multiple zones "protect[s] your applications from the failure of a single location" (AWS: Regions and Availability Zones^[2]). The catch is the same as any backup: a cloud target must be restore-tested against the RTO, because egress and rehydration time are real.

Multiple processing sites and reciprocal agreements

Two related strategies round out the site picture. Multiple (redundant) processing sites means running the workload across two or more facilities the organization already operates, so that if one is lost the others carry the load. When both run live and share the workload (active/active), failover is effectively instantaneous and the second site earns its keep every day rather than sitting idle: the strongest, and most expensive, posture. A reciprocal agreement (mutual aid pact) is the opposite end: two organizations agree to host each other's processing in an emergency. It is cheap but unreliable at disaster scale: the partner may lack spare capacity, hardware/software may be incompatible, a regional event can hit both parties at once, and hosting a competitor's data raises confidentiality concerns. NIST notes reciprocal agreements and memoranda of understanding among alternate-site options but they are widely treated as a last resort, not a primary strategy (NIST SP 800-34 Rev. 1, §3.4.2^[1]).

This section covers the two controls that serve dimensions the site does not: backups (the RPO/data dimension) and resilience (avoiding the outage entirely). Read the two-dimensions framing from the first section first: a site answers how fast, backups answer how much data, resilience answers can we skip recovery altogether.

Backup storage location: onsite, offsite, and cloud

Where a backup lives decides whether it survives the disaster that destroyed production. Onsite backups give the fastest restore for everyday recovery (a deleted file, a corrupt database) but share the fate of the primary in a fire, flood, or site-wide ransomware event. Offsite backups (physically distant media or a remote facility) survive the local disaster, which is exactly why NIST states it plainly: "It is good business practice to store backed-up data offsite," and the first criterion for choosing an offsite facility is "distance from the organization and the probability of the storage site being affected by the same disaster as the organization's primary site" (NIST SP 800-34 Rev. 1, §3.4.2^[1]). Cloud storage is the modern offsite tier: it adds geographic separation by default and removes the courier/tape-rotation overhead, at the price of restore time bounded by network egress.

The durable rule the exam expects is 3-2-1: keep at least three copies of the data, on two different media types, with at least one copy offsite, the widely taught industry formulation of the same offsite principle. The offsite copy is the load-bearing element; an onsite-only backup is the most common recovery-design failure because one event takes both the data and its only copy. Whatever the location, NIST is explicit that the copy must be proven restorable: "Backup tapes should be tested regularly to ensure that data are being stored correctly and that the files may be retrieved without errors or lost data" (NIST SP 800-34 Rev. 1, §3.4.2 n.25^[1]).

Backup types: the backup-time vs restore-time trade

The three backup methods differ in what they copy, which sets a direct trade between how long the backup takes and how long the restore takes:

Method	What it copies	Backup time	Restore time	Archive bit
Full	All selected data, every run	Longest	Shortest (one set)	Clears it
Incremental	Only data changed since the last backup of any kind	Shortest	Longest (full + every increment in order)	Clears it
Differential	All data changed since the last full backup	Grows each day	Medium (full + one differential)	Leaves it set

The testable contrast: incremental minimizes nightly backup time but a restore needs the last full plus every incremental in sequence; differential takes longer each night (it re-copies everything changed since the full) but a restore needs only the last full plus one differential. The archive-bit behavior is the classic discriminator: incremental and full clear the archive bit, differential does not, which is the mechanism behind "since last backup" vs "since last full."

Resilience, high availability, and fault tolerance: not synonyms

Resilience controls absorb a component failure so you never invoke a site or a restore at all, but the exam separates two promises. Fault tolerance means a component can fail with zero interruption: a redundant element carries the load transparently. High availability (HA) means the service is restored so quickly that downtime is minimal, typically through clustering and automatic failover, but not necessarily zero. The distinction is testable: a fault-tolerant design tolerates the failure invisibly; an HA design recovers from it fast.

The workhorse fault-tolerance technology for storage is RAID (Redundant Array of Independent Disks), which keeps data available across a disk failure. NIST lists RAID among the redundancy and fault-tolerance processes that "store data on more than one drive and eliminate loss of data from single drive failures" (NIST SP 800-34 Rev. 1, §5.1.3 / §5.3.3^[1]). Know the common levels: RAID 0 stripes for performance and provides no redundancy (a single disk loss destroys the array, a deliberate trap); RAID 1 mirrors; RAID 5 stripes with one parity block and survives one disk failure; RAID 6 uses double parity and survives two; RAID 10 mirrors then stripes for both speed and redundancy. RAID protects against disk failure: it is not a backup, because it faithfully replicates deletion, corruption, and ransomware to every mirror.

Quality of Service (QoS) is the availability control for the network: it reserves bandwidth for and prioritizes critical traffic so that, under contention, a flood of low-priority traffic cannot starve the systems that must stay up. The unifying design lesson across all of these: redundancy at one layer does not imply redundancy at another. A fault-tolerant RAID array on a server with a single power supply and one network uplink is still a single point of failure: true resilience eliminates the SPOF at every layer the service depends on. The figure below groups these resilience controls into their three families, each promising something different.

This section maps question shapes to the right answer. Read the others first; this is the pattern layer.

Pattern 1, "Given this RTO, which site?" A stem states an RTO (or MTD) and asks for the recovery site. Map it: near-zero / minutes → hot site (or multiple active processing sites); hours-to-days → warm site; days-to-weeks with cost pressure → cold site. The trap is picking the fastest site regardless of cost: the CISSP-correct answer is the least expensive option that still meets the RTO, per the cost-balance point (NIST SP 800-34 Rev. 1, §3.2.1^[1]).

Pattern 2, "Cheapest vs fastest activation." A stem asks which site is cheapest to maintain (answer: cold) or which activates fastest (answer: hot). Hold the two ends straight: cold = cheapest to hold but slowest to activate; hot = costliest to hold but fastest to activate; warm is the middle on both. The trap conflates standing cost with activation speed: they move in opposite directions across the spectrum.

Pattern 3, "The backup didn't survive the disaster." A stem describes a fire/flood/ransomware that destroyed both production and its backup, then asks what the design got wrong. Answer: the backup was onsite only; the fix is an offsite/cloud copy and the 3-2-1 rule. The trap is an answer that adds more onsite copies or a bigger array, which does nothing against a site-wide event.

Pattern 4, "Fastest restore vs smallest nightly window." A stem optimizes the backup schedule. Smallest nightly backup window → incremental (copies only since the last backup). Fastest/simplest restore → differential (restore needs only the last full plus one differential) or, simplest of all, a recent full. The trap is choosing incremental for fast recovery: incremental has the slowest restore because you replay the full plus every increment in order.

Pattern 5, "RAID is not a backup." A stem presents a RAID array and a deletion/corruption/ransomware event and asks whether RAID covers it. Answer: no, RAID protects against disk hardware failure only and faithfully replicates logical damage to every mirror. The trap is treating RAID 0 as protective (it has no redundancy) or treating any RAID level as a substitute for offsite backups.

Pattern 6, "Fault tolerance vs high availability." A stem describes a requirement for zero interruption versus minimal downtime. Zero interruption on component failure → fault tolerance (redundant component takes over transparently). Fast recovery via clustering/failover, downtime minimized but not zero → high availability. The trap uses the two terms as synonyms; the exam rewards the candidate who keeps the promises distinct.

Pattern 7, scope boundaries. A stem that asks how to derive the RTO/RPO or rank process criticality is business-continuity (the BIA), not this subtopic; a stem about executing the failover and failback during the disaster is disaster-recovery; a stem about proving the plan works with tabletop/parallel/full-interruption tests is dr-testing. Recovery strategy owns only the selection of site, backup regime, and resilience controls against the targets it was handed.