A backup is the last line of defence: when prevention and detection have failed, the ability to restore is what decides whether an incident is an inconvenience or a company-ending event. This page is the technical recovery complement to Business Continuity, which covers the BCP/contingency process (priorities, roles, planning flow). Here we cover how data and systems are actually copied, stored, restored and tested.
Backup protects availability in the CIA Triad, and also integrity (restoring a known-good state).
Backup Types
| Type | What is copied | Backup speed / size | Restore |
|---|---|---|---|
| Full | Everything selected | Slowest, largest | Fastest: one set |
| Incremental | Only changes since the last backup of any type | Fastest, smallest | Slowest: full + every incremental in order |
| Differential | Changes since the last full | Medium, grows daily | Medium: full + latest differential |
| Snapshot | Point-in-time view of a volume/VM (usually copy-on-write) | Near instant | Fast, but often stored on the same system |
| Continuous (CDP) | Every write is journalled | Constant | Roll back to any moment |
Sun Mon Tue Wed Thu
FULL inc inc inc inc restore Thu = Full + Mon + Tue + Wed + Thu
FULL diff diff diff diff restore Thu = Full + Thu
- A snapshot is not a backup on its own: if it lives on the same storage array, the same failure or attacker takes both.
- Database backups need application consistency (quiesce or use native dump/log shipping), otherwise the copy may be corrupt.
- Choose the strategy from RPO/RTO (below), not habit: frequent incrementals lower data loss; periodic synthetic fulls shorten restore chains.
3-2-1 and Beyond
3 copies of the data (production + 2 backups)
2 different media/storage types
1 copy off-site
Modern extension, 3-2-1-1-0:
- +1 copy that is offline, air-gapped or immutable
- 0 errors after restore verification
| Copy type | Meaning | Defeats |
|---|---|---|
| Off-site | Different location or region | Fire, flood, site loss |
| Offline / air-gapped | Disconnected from the network (tape, rotated disk, logically isolated vault) | Network-borne malware, ransomware |
| Immutable (WORM) | Cannot be altered or deleted for a retention period, even by admins (object lock, retention lock) | Attacker with stolen admin credentials |
Separate the backup administration identity from the normal domain admin identity and require MFA; attackers routinely hunt for backup consoles first (see IAM).
Protecting the Backups Themselves
- Encrypt backups in transit and at rest; keep keys separate from the backup data and back up the keys too (see Cryptographic Solutions). A lost key means a lost backup.
- Integrity: hash or sign backup sets and verify them, so tampering or silent corruption is detected.
- Access control: least privilege, separate credentials, no standing delete rights, restricted network path to the backup server.
- Classification-aware retention: backups contain the same sensitive data as production, so they inherit its classification, legal retention and secure-destruction obligations (see Data Lifecycle and Data Maintenance).
- Media handling: label, track, transport securely and sanitise or destroy media at end of life.
RPO, RTO, MTD
| Term | Question it answers | Set by |
|---|---|---|
| RPO (Recovery Point Objective) | How much data can we afford to lose, measured in time? | Business impact; drives backup frequency |
| RTO (Recovery Time Objective) | How long can the system be down before recovery must complete? | Business impact; drives recovery architecture |
| MTD / MTPD (Maximum Tolerable Downtime) | How long can the business function be unavailable before damage is unacceptable? | Business impact analysis |
| WRT (Work Recovery Time) | Time to verify data and return to normal work after the system is back | Operations |
last good disaster system business fully
backup restored back to normal
|<-- RPO -->| |<----- RTO ----->|<--- WRT --->|
|<--------------- MTD ---------->|
Relationship: RTO + WRT <= MTD
Lower RPO/RTO means higher cost: continuous replication and hot standby cost far more than nightly backups and cold rebuilds. Values come from the business impact analysis in the BCP; this page turns them into design.
Worked example
Order system: BIA says losing more than 15 minutes of orders is unacceptable (RPO 15 min), the shop must be back within 1 hour (RTO 1 h), and the business tolerates at most 4 hours of outage (MTD 4 h).
| Requirement | Design consequence |
|---|---|
| RPO 15 min | Nightly backup is not enough. Use database log shipping/replication every few minutes plus hourly incrementals. |
| RTO 1 h | Restoring a multi-hour full backup from tape is too slow. Keep a warm standby with replicated data and scripted failover. |
| MTD 4 h | Leaves 3 h for WRT: reconciliation of in-flight orders, testing, comms. Check WRT actually fits. |
| Ransomware | Add an immutable daily copy; accept that this tier restores to a 24 h RPO and a longer RTO, and document it. |
Recovery Site Models
| Model | State | RTO | Cost |
|---|---|---|---|
| Hot site | Fully equipped, data continuously replicated, ready to run | Minutes to hours | Highest |
| Warm site | Hardware and connectivity present, data restored from recent backups | Hours to days | Medium |
| Cold site | Space, power, network only; everything brought in | Days to weeks | Lowest |
| Mobile / reciprocal | Trailer or agreement with a partner | Varies | Varies, with caveats on capacity and trust |
| Cloud / DRaaS | Replicated VMs or infrastructure-as-code in another region, pay for compute only when failing over | Minutes to hours | Pay-as-you-go |
Cloud recovery is attractive because capacity is elastic and standby is cheap, but it needs tested networking, identity and DNS cutover (see Cloud Security). Keep the recovery environment in a separate account/subscription with separate credentials.
Site topologies: active-passive (standby takes over) versus active-active (both serve traffic; best RTO, hardest consistency).
Failover and Failback
- Failover: switching production to the recovery environment (DNS/load balancer change, promote replica, start standby systems).
- Failback: returning to the primary once repaired. It is a second migration: data written during the outage must be synchronised back, and it should be planned, not rushed.
- Automate where safe, but require a human decision for declaring a disaster to avoid flapping or split-brain (two nodes both believing they are primary).
Disaster Recovery Plan Contents
- Scope, assumptions and the declared RPO/RTO per system (tiered by criticality)
- Activation criteria and who can declare a disaster
- Contact lists and escalation (team, vendors, regulators), including out-of-band communication
- Inventory of systems, dependencies and recovery order (identity, DNS, network, then databases, then applications)
- Step-by-step recovery runbooks, written so someone unfamiliar can follow them
- Location of backups, credentials, encryption keys and licences (stored where an outage will not lock you out)
- Alternate site details and failover/failback procedures
- Validation: how to confirm data and service are healthy before declaring recovery complete
- Review and update schedule; change triggers (see Change Management)
Testing
An untested backup is a hope, not a control.
| Test | What happens | Disruption |
|---|---|---|
| Read-through / checklist | Owners review the plan for accuracy | None |
| Tabletop | Team talks through a scenario around a table | None |
| Walkthrough | Teams step through procedures in detail against real systems' documentation | Minimal |
| Simulation | Scenario played out with real tools, but no production impact | Low |
| Parallel | Recovery systems brought up and run alongside production | Low to medium |
| Full interruption / failover | Production really moves to the recovery site | High, highest assurance |
Record measured restore times and compare them with RTO; fix gaps; repeat at least annually and after major changes.
Ransomware Resilience
Ransomware turns backups into the primary target: attackers delete shadow copies, wipe backup catalogues and encrypt network shares first.
- Immutable and offline copies out of reach of domain credentials (see 3-2-1-1-0).
- Keep backup infrastructure off the production domain or tightly segmented.
- Restore into a clean environment: rebuild from known-good images, rotate all credentials, and confirm the entry point is closed first, otherwise you restore into re-infection. Coordinate with the Incident Response Process (eradication before recovery) and preserve evidence for forensics.
- Scan restore points for malware and find the last clean point (the infection may predate the latest backups).
- Pre-define the "restore everything" runbook and measure how long it really takes: a petabyte over a 1 Gbps link is days.
Monitoring and Restore Verification
- Alert on failed, skipped or missing jobs, sudden changes in backup size (mass encryption or deletion), changes to retention settings, and backup-admin logins. Feed these to the SIEM.
- Run automated restore tests (restore a sample, compare checksums, boot the VM, run an application smoke test). This is the "0 errors" in 3-2-1-1-0.
- Track metrics: success rate, restore time vs RTO, recovery point age vs RPO, capacity, and number of untested systems.
Key Points
- Backups protect availability and are the last control that works after compromise; design them to survive an attacker with admin rights.
- Follow 3-2-1-1-0: multiple copies, different media, off-site, one immutable/offline, zero restore errors.
- RPO sets backup frequency, RTO sets recovery architecture, and RTO + WRT must fit within MTD.
- Backups inherit data classification: encrypt, control access and destroy on schedule.
- Test restores regularly; only measured recovery times count.
Related
- Business Continuity (BCP process and contingency planning)
- Incident Response Process
- Data Lifecycle, Data Maintenance
- Cloud Security, Change Management, Malware
- TryHackMe: Incident Response Fundamentals, Defensive Security Intro