Backup, resilience and recovery strategies

The business impact analysis tells the organization how quickly each activity must return and how much data it can afford to lose. Recovery strategies are the means of meeting those objectives. They range from nightly backups restored onto replacement hardware, which is cheap but slow, to fully redundant systems running in two locations at once, which is fast but expensive. Choosing well means matching each system's strategy to its recovery point objective (RPO) and recovery time objective (RTO), and then proving through testing that the strategy actually works.

This lesson covers the CISSP outline's sub-domain 7.10, implement recovery strategies: backup storage strategies, recovery site strategies, multiple processing sites, and system resilience, high availability, quality of service and fault tolerance. Recovery sites are covered in more depth in Lesson 11. In an era of ransomware, backups have also become a security control in their own right, and their protection is now a central concern of security operations.

Backup types and schedules

A full backup copies all selected data. An incremental backup copies only the data changed since the last backup of any kind; it is fast and small to create, but restoring requires the last full backup plus every incremental since. A differential backup copies everything changed since the last full backup; each differential grows through the week, but a restore needs only the full plus the latest differential. Synthetic full backups, built by combining a previous full with later incrementals on the backup system, give the restore speed of a full without the load of reading all source data again. Many modern systems use continuous data protection or frequent snapshots, which capture changes every few minutes.

The backup schedule sets the achievable RPO. If a database is backed up nightly at 01:00 and fails at 23:00, nearly a full day of transactions is lost. An RPO of 15 minutes requires transaction log backups or replication at least every 15 minutes. Retention, meanwhile, decides how far back the organization can go, which matters when corruption or an intrusion goes unnoticed for weeks. Retention periods should reflect legal and business needs and the likely time to detect a problem; Lesson 5 showed that intrusions can remain undetected for weeks.

# Estimate storage for a weekly-full, daily-incremental scheme with 8 weeks of retention (synthetic)
full_tb = 40.0          # size of one full backup
daily_change = 0.03     # share of data changed per day
dedupe_ratio = 3.0      # reduction achieved by deduplication and compression
weeks_kept = 8
incr_tb = full_tb * daily_change
per_week = full_tb + 6 * incr_tb
raw_total = per_week * weeks_kept
stored = raw_total / dedupe_ratio
print(f'One incremental: {incr_tb:.1f} TB, one week: {per_week:.1f} TB')
print(f'Raw for {weeks_kept} weeks: {raw_total:.0f} TB, stored after reduction: {stored:.0f} TB')
for rpo_hours in (24, 4, 0.25):
    copies_per_day = 24 / rpo_hours
    print(f'RPO {rpo_hours:>5} h needs at least {copies_per_day:4.0f} protection points per day')

One incremental: 1.2 TB, one week: 47.2 TB
Raw for 8 weeks: 378 TB, stored after reduction: 126 TB
RPO    24 h needs at least    1 protection points per day
RPO     4 h needs at least    6 protection points per day
RPO  0.25 h needs at least   96 protection points per day

The 3-2-1 rule and its modern extension

The traditional 3-2-1 rule says to keep at least three copies of important data, on two different types of media or storage, with one copy offsite. Ransomware has pushed organizations to extend this to 3-2-1-1-0: three copies, two media, one offsite, one copy offline, air-gapped or immutable so that it cannot be altered or deleted even by someone with administrator credentials, and zero errors in backup verification and restore testing. Immutable storage, sometimes implemented as write-once-read-many object storage with a retention lock, is now widely offered by backup products and cloud providers.

Backups must be protected as carefully as production. Adversaries who gain administrative access often look for backup systems and try to delete or encrypt them before triggering ransomware. Defensive practices include separate credentials and administrative domains for the backup system, multi-factor authentication for backup administration, immutability locks that even administrators cannot shorten, encryption of backup data with keys managed separately, alerts on deletion or changes to retention, and logging of all backup administration to the SIEM. Backups also contain everything sensitive the organization holds, so access to restore data must be controlled and logged.

# Check backup jobs against the 3-2-1-1-0 rule (synthetic inventory)
systems = {
    'ERP database':   {'copies': 3, 'media': {'disk', 'object'}, 'offsite': True, 'immutable': True, 'last_restore_ok': True},
    'File servers':   {'copies': 3, 'media': {'disk', 'tape'}, 'offsite': True, 'immutable': False, 'last_restore_ok': True},
    'HR SaaS':        {'copies': 1, 'media': {'vendor'}, 'offsite': True, 'immutable': False, 'last_restore_ok': None},
    'Plant historian':{'copies': 2, 'media': {'disk'}, 'offsite': False, 'immutable': False, 'last_restore_ok': False},
}
for name, s in systems.items():
    gaps = []
    if s['copies'] < 3: gaps.append('fewer than 3 copies')
    if len(s['media']) < 2: gaps.append('single media type')
    if not s['offsite']: gaps.append('no offsite copy')
    if not s['immutable']: gaps.append('no offline or immutable copy')
    if s['last_restore_ok'] is not True: gaps.append('no verified restore')
    status = 'meets 3-2-1-1-0' if not gaps else 'ERROR ' + '; '.join(gaps)
    print(f'{name:16s} {status}')

ERP database     meets 3-2-1-1-0
File servers     ERROR no offline or immutable copy
HR SaaS          ERROR fewer than 3 copies; single media type; no offline or immutable copy; no verified restore
Plant historian  ERROR fewer than 3 copies; single media type; no offsite copy; no offline or immutable copy; no verified restore

The software-as-a-service result is common and easily missed. Under the shared responsibility model, a SaaS provider keeps its service running but usually does not promise to restore an individual customer's data deleted by a user, a misconfigured integration or an intruder, beyond a short retention window. Organizations that depend on SaaS for critical data should read the provider's terms and consider third-party backup of that data.

Restore testing and the zero in 3-2-1-1-0

A backup that cannot be restored is not a backup. Restore testing confirms that data can be recovered, that it is complete and consistent, and that it can be recovered within the RTO. Tests range from restoring individual files on request, to scheduled restores of whole databases into an isolated environment with integrity checks, to full recovery of an application stack. Automated restore verification, offered by many backup products, boots backups in an isolated environment and checks that services start.

The restore test success rate, the proportion of test restores that complete successfully and within the target time, is the key metric. Because the number of tests in any period may be small, managers should be careful not to over-read a single good quarter. Reporting a confidence range alongside the rate gives a more honest picture.

import random, math
random.seed(2026)
# Simulate quarterly restore tests and report success rate with a 95 % Wilson interval
def wilson(k, n, z=1.96):
    p = k / n
    d = 1 + z * z / n
    c = (p + z * z / (2 * n)) / d
    h = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / d
    return c - h, c + h
true_rate = 0.92
for quarter, n in [('Q1', 12), ('Q2', 12), ('Q3', 40), ('Q4', 40)]:
    k = sum(random.random() < true_rate for _ in range(n))
    lo, hi = wilson(k, n)
    print(f'{quarter}: {k}/{n} restores met RTO = {k/n:5.1%}  (95 % range {lo:5.1%} to {hi:5.1%})')

Q1: 12/12 restores met RTO = 100.0%  (95 % range 75.7% to 100.0%)
Q2: 12/12 restores met RTO = 100.0%  (95 % range 75.7% to 100.0%)
Q3: 36/40 restores met RTO = 90.0%  (95 % range 76.9% to 96.0%)
Q4: 37/40 restores met RTO = 92.5%  (95 % range 80.1% to 97.4%)

With only twelve tests a quarter, even a perfect result is consistent with a true success rate well below target. Increasing the number of tests, mostly through automation, narrows the range and builds justified confidence. Every failed restore should be investigated like an incident, because it reveals a gap that would otherwise be discovered during a real disaster.

Resilience, high availability and fault tolerance

Backups recover from loss; resilience designs reduce the chance of loss in the first place. High availability (HA) designs keep a service running despite the failure of a component, typically through redundant servers in a cluster with automatic failover. Fault tolerance goes further: the system continues operating without interruption when a component fails, for example through redundant power supplies or mirrored disks. RAID (redundant array of independent disks) is a classic fault tolerance technique; RAID 1 mirrors data across disks and RAID 5 and 6 use parity to survive one or two disk failures. RAID protects against disk failure only; it is not a backup, because deletion, corruption or encryption is faithfully copied to every disk.

Availability is often expressed as a percentage, such as 99.9 % (about 8.8 hours of downtime a year) or 99.99 % (about 53 minutes). Components in series multiply their availabilities, so a service that needs five components each at 99.9 % is less available than any one of them; redundant components in parallel greatly improve availability, provided their failures are independent. Common-mode failures, such as both servers sharing a power circuit, a software bug or an administrator mistake, break that independence.

# Availability of components in series and in redundant pairs
def series(*a):
    r = 1.0
    for x in a: r *= x
    return r
def parallel(*a):
    r = 1.0
    for x in a: r *= (1 - x)
    return 1 - r
hours = 8766
single = 0.999
chain = series(single, single, single, single, single)
redundant = series(*[parallel(single, single)] * 5)
for name, a in [('one component', single), ('five in series', chain), ('five redundant pairs in series', redundant)]:
    print(f'{name:32s} availability {a:.5%}  downtime {(1 - a) * hours:6.2f} h/year')

one component                    availability 99.90000%  downtime   8.77 h/year
five in series                   availability 99.50100%  downtime  43.74 h/year
five redundant pairs in series   availability 99.99950%  downtime   0.04 h/year

Quality of service (QoS) is also listed in the outline: network QoS prioritizes critical traffic, such as voice or control system traffic, so that it continues to function when links are congested during an incident or a recovery. Other resilience measures include redundant network links from different carriers using different physical paths, uninterruptible power supplies and generators, geographically distributed cloud deployments across availability zones or regions, and avoiding single points of failure in people as well as technology, by cross-training staff.