Business Continuity & Disaster Recovery

#Business Impact Analysis and Recovery Objectives

#What is this?

A business impact analysis (BIA) asks each part of the business: if this process stopped, what would it cost per hour or per day, and how long could we survive without it? The answers become the recovery targets that every backup and DR design must meet.

#Why it matters

Without a BIA, DR spending is guesswork: either gold-plating systems nobody needs fast, or discovering mid-ransomware that the payment system had a one-week restore time. Interviewers use RTO and RPO to test whether you can design for a requirement rather than for a technology.

#How it works

Time ───────────────────────────────────────────────────────────────────────►
          last good backup          disaster                 service restored
               │                       │                            │
               │◄──────── RPO ────────►│◄──────────── RTO ─────────►│
               │  data you can afford  │  downtime you can afford    │
               │  to lose              │                             │
                                       │◄────────────── MTD ─────────────────►│
                                          beyond this, the business may not survive

BIA steps:

1. Identify business processes and their owners.
2. Map each process to the systems, people, suppliers and data it needs.
3. Estimate the impact of an outage over time: financial, regulatory, reputational, safety.
4. Set MTD, RTO and RPO for each process.
5. Feed the results into the continuity strategy and the budget.

In practiceA BIA ends up as a table that engineering can design against:

The "depends on" column is where plans usually fail: payments can't recover in 2 hours if the identity provider it needs has a 24-hour RTO.

📰

Real incident — Maersk and NotPetya (2017). Destructive malware wiped tens of thousands of Maersk machines in hours, including every online domain controller. The company recovered its Active Directory from a single domain controller in Ghana that happened to be offline during a power cut. Global shipping operations ran on manual workarounds for about ten days; the cost was estimated at around $300 million. Identity was the hidden dependency of everything.

🎯

On the job. Ask every critical service owner two questions: "what's your real RTO, measured in the last test?" and "what do you depend on to come back?" The answers rarely match the documented plan.

#Security angle

Security incidents are now the most likely "disaster." Ransomware recovery is a DR scenario, but with a twist: you must be sure backups are clean and the attacker is gone before restoring, or you restore the attacker too.

#Backup Strategies

#What is this?

The ways data is copied so it can be restored.

#Why it matters

The backup type decides how long backups take, how much storage they need and, crucially, how long and complex a restore is.

#How it works

In practice"Is this backup actually restorable and immutable?" is answerable from the command line:

$ restic -r s3:s3.amazonaws.com/acme-backups snapshots --latest 3
ID        Time                 Host    Paths
4f1c2a9e  2026-10-11 02:00:04  db01    /var/lib/postgresql        ← last night's snapshot exists
$ restic -r s3:… check --read-data-subset=5%                     ← actually read data back, not just list it
no errors were found
$ aws s3api get-object-lock-configuration --bucket acme-backups
{ "ObjectLockConfiguration": { "ObjectLockEnabled": "Enabled",
  "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 35 } } } }   ← nobody can delete for 35 days

📰

Real incident — GitLab database deletion (2017). An engineer accidentally deleted the production database directory while fixing replication. GitLab then discovered that none of its five backup and replication methods worked as expected: scheduled dumps had been silently failing. Recovery came from a staging snapshot taken six hours earlier, and about six hours of data was lost. They livestreamed the recovery and published a famously honest postmortem.

🎯

On the job. Alert on backup failures and on backups that are suspiciously small, and run restore tests on a schedule. The only proof a backup works is a restore.

#Security angle

Backups are a high-value target: they contain everything. Encrypt them, store them in a separate security domain with separate credentials, and alert on deletion attempts.

#Recovery Sites and High Availability

#What is this?

Where systems run when the primary site is unavailable, and how designs avoid single points of failure.

#Why it matters

The recovery site choice is a cost-versus-RTO trade-off, and it is a classic exam question.

#How it works

Cloud equivalents (fastest to slowest recovery): multi-site active–active, warm standby (a scaled-down live copy), pilot light (core data replicated, servers off until needed), and backup and restore.

High availability building blocks: redundant components and power, clustering and load balancing, RAID (redundant array of independent disks — RAID 1 mirroring, RAID 5 striping with parity tolerates one disk failure, RAID 6 two, RAID 10 mirrored stripes), multiple availability zones or regions, and avoiding shared dependencies (one DNS provider, one identity provider).

📰

Real incident — OVHcloud data-centre fire (2021). A fire destroyed one data centre and damaged another at OVHcloud's Strasbourg site. Customers who had kept their backups in the same site — sometimes the same building — lost data permanently. "Off-site" has to mean a different failure domain, not just a different server.

📰

Real incident — CrowdStrike outage recovery (2024). When a faulty agent update crashed millions of Windows machines, many organisations had to fix each machine by hand in safe mode. Those using BitLocker disk encryption first needed each machine's recovery key — and some had stored those keys on systems that were themselves down. Recovery dependencies include the secrets you need to recover.

🎯

On the job. Keep break-glass essentials — recovery keys, admin credentials, network diagrams, the DR runbook, contact lists — available offline or in a separate provider, because the incident may take down the place you normally keep them.

#Security angle

A DR region must have the same security controls as production: logging, guardrails, secrets and detection. Attackers like DR environments because they are rarely watched.

#Testing the Plan

#What is this?

The different ways to prove a continuity or DR plan works, in order of increasing realism and risk.

#Why it matters

An untested plan fails on first use: contact lists are stale, the runbook references a decommissioned server, the restore takes four times the RTO.

#How it works

After every test or real event, run a lessons-learned review and update the plan. See postmortems.

In practiceA useful tabletop is a timed scenario with injects, not a slideshow:

09:00  Inject 1: Helpdesk reports staff can't open files; ransom note on file server.
09:15  Inject 2: Backup admin finds backup server console shows "repository deleted".
09:40  Inject 3: A journalist emails asking about "the ransomware attack on your company".
10:00  Inject 4: Cyber insurer asks whether you have engaged their panel responder yet.
Questions at each inject: Who decides? What do we isolate? Who do we tell, by when? What do we restore first?

🎯

On the job. Measure each exercise: time to declare an incident, time to first containment action, time to a working restore of one critical system. Track them across exercises like any other metric.

#Security angle

Include a ransomware scenario: restore from immutable backups into an isolated environment, verify the data is clean, and time it against the RTO. That is the test most organisations have never run.