Business continuity and disaster recovery

On Wednesday, November 4, 2026, Jordan spent the evening at Prairie Paws Veterinary Clinic pretending the practice-management server had died. Nothing was actually broken. Keisha had scheduled a restore test: take last night's backup, restore it to a spare machine, and see whether the clinic could open patient records, book appointments and print invoices from the restored copy. It took three hours and forty minutes, and it found two problems. The license file for the practice software was not included in the backup, and nobody had written down the order in which the database and application services had to start. Both were fixed by Friday. Keisha said the test was a success precisely because it found problems on a quiet Wednesday rather than on the day the server really failed.

This lesson covers how organizations keep operating when something goes badly wrong, whether a cyberattack, a hardware failure, a fire, a flood or a long power cut. The exam expects you to explain why disaster recovery and business continuity planning matter. You also need the vocabulary used to describe recovery goals, backup methods and recovery sites.

Continuity and recovery

Business continuity and disaster recovery are related but different. A business continuity plan, or BCP, describes how the organization keeps its most important functions running during and after a disruption, including manual workarounds, alternative locations and how people communicate. A disaster recovery plan, or DRP, is narrower: it describes how IT systems and data are restored after a disruption. The DRP is usually one part of the BCP. A bakery that keeps selling bread with a cash box and a paper order book while its point-of-sale system is down is following its continuity plan; the technician restoring the point-of-sale software from backup is following the recovery plan.

Incident response, from Lesson 9, overlaps with both. A ransomware attack starts as an incident and quickly becomes a recovery problem, which is why many organizations test all three plans together.

Business impact analysis

Planning starts with a business impact analysis, or BIA. It identifies the organization's critical functions, the systems and people each one depends on, and the impact of losing each function over time: money lost, customers lost, legal or safety consequences and damage to reputation. From the BIA come the recovery targets that drive every technical decision.

The two objectives drive different choices. RPO decides how often data must be backed up or copied: an RPO of four hours means backups or replication at least every four hours. RTO decides how fast restoration must be: an RTO of six hours rules out a plan that depends on ordering new hardware. Before the November test, the clinic's backups ran only once a night, which meant a failure late in the afternoon could lose a whole day of records, far outside the four-hour RPO. After the test, Brightline added backups every three hours during clinic hours.

Backup types

A backup is a copy of data that can be used to restore it. There are three classic types, and they differ in how much they copy and how many pieces are needed to restore.

• A full backup copies everything selected. It is the simplest to restore but the slowest and largest.
• An incremental backup copies only what changed since the last backup of any kind. Each one is small and fast, but a restore needs the last full backup plus every incremental since.
• A differential backup copies everything that changed since the last full backup. Each one grows during the week, but a restore needs only the last full backup and the latest differential.

Modern backup tools often blur these lines with techniques such as synthetic full backups, which assemble a new full backup from earlier pieces without copying everything again. Snapshots, which capture the state of a disk or virtual machine at a point in time, are fast and useful, but a snapshot stored on the same system is not a backup on its own, because losing the system loses the snapshot too.

The 3-2-1 rule and ransomware

The best-known rule of thumb for backups is 3-2-1: keep at least three copies of important data, on two different types of storage, with one copy offsite. Ransomware has added a fourth requirement. Attackers who reach a network now look for backups and try to delete or encrypt them before deploying ransomware, so at least one copy must be offline or immutable. Immutable storage cannot be changed or deleted until a set retention period ends, even by an administrator. Some guidance extends the rule to 3-2-1-1-0: one copy offline or immutable, and zero errors when backups are tested.

Backup systems must also be protected like any other critical system. Brightline used separate accounts with multi-factor authentication for its backup console, kept those accounts out of the clients' normal directory, encrypted backup data and alerted on any attempt to delete backups or shorten retention. Cloud services such as hosted email and file storage also need backups. Providers keep their services running, but under the shared responsibility model they usually do not promise to restore data that a customer, or an attacker using the customer's account, deleted.

Redundancy and high availability

Redundancy reduces the chance that one failure stops a system. Examples include RAID disk arrays, two power supplies, an uninterruptible power supply, a second internet connection and clustered servers. Redundancy is valuable, but it is not a backup. A RAID array copies a deleted or encrypted file to every disk instantly. A backup is a separate copy from an earlier point in time, and that time difference is what makes recovery possible.

At Kettle & Crumb, redundancy was mostly about keeping sales going. The card terminals could switch to a cellular connection if a shop's internet failed, and they could store a limited number of transactions offline for a short time. A small uninterruptible power supply kept the network equipment running long enough to close the till cleanly during a power cut.

Recovering from ransomware

Ransomware recovery differs from recovery after a hardware failure in one important way: the attacker may still be inside. Restoring systems onto a network the attacker still controls invites a second attack. Recovery therefore waits until the incident response team is confident the attacker's access has been removed, compromised accounts have been reset and the way in has been closed. Backups are restored to clean, rebuilt systems, starting with the most critical functions identified in the BIA, and each restored backup is scanned before use, because the malware may have been present for days before the encryption began. That is another reason to keep backups for several weeks: the newest backup is not always a clean one. Paying a ransom does not guarantee working decryption, may break sanctions or other laws, and leaves the organization a known payer, which is why tested, protected backups are the most important ransomware control a small business can have.

Recovery sites

If a whole location is lost, systems must run somewhere else. Recovery sites are described by how ready they are.

Small organizations rarely own a second site. For Prairie Paws, Brightline's plan was to restore the server to a cloud virtual machine if the clinic building was unusable, with staff working from the second location. That plan only works if the cloud restore has been tested, which was the next item on Keisha's list.

Writing and testing the plans

A continuity plan should be short enough to use under stress. It names who declares a disruption and who leads the response, lists the critical functions with their recovery targets, gives manual workarounds, sets out how staff, customers and suppliers will be contacted, and points to the technical recovery procedures. Printed copies and offline contact lists are essential, because the plan is most needed exactly when systems are down.

Plans are tested at increasing levels of realism. A checklist review confirms that the plan is current. A tabletop exercise walks the team through a scenario in a meeting room. A walkthrough or simulation practices specific steps. A parallel test runs recovered systems alongside production to compare results. A full interruption test actually switches over, which is rare because of the risk. The restore test at Prairie Paws was a simulation of one system. A tabletop exercise on a ransomware scenario with the clinic's owner and office manager is planned for January 2027, and Lesson 12 uses a similar scenario.