Chapter 25 — Backup and recovery
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 Backup design"]
N2["25.2 Testing restores"]
N3["25.3 Recovery objectives"]
N4["25.4 Recovery plan"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 Backup design"]
N2["25.2 Testing restores"]
N3["25.3 Recovery objectives"]
N4["25.4 Recovery plan"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 Backup design]
|
v
[25.2 Testing restores]
|
v
[25.3 Recovery objectives]
|
v
[25.4 Recovery plan]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) design backups for different threats; (2) test restores; (3) set recovery objectives with business owners.
25.1 Backup design
Backups protect against hardware failure, mistakes and ransomware, but each threat needs different design. Hardware failure needs a copy elsewhere; mistakes need older versions; ransomware needs copies attackers cannot reach or alter. Aisha reviews Ashfield's backups: nightly copies to a storage device in the head office, reachable from the network. She recommends an additional offline or immutable copy, kept away from the head office, so one event cannot destroy everything. The chief executive approves the cost of an additional copy stored with a specialist provider in another town.
25.2 Testing restores
A backup is only useful if it can be restored. Aisha asks when Ashfield last restored a full system from backup. Nobody remembers. She organises a test restore of the shared folders to a separate computer and compares file fingerprints with the originals using hashlib. A few files fail because they were open during backup. She recommends scheduling backups when files are closed and testing restores every quarter. The IT manager adds the quarterly restore test to the calendar and records each result with the number of files checked and verified.
25.3 Recovery objectives
Aisha works with managers to set recovery objectives. For core banking, they accept losing at most fifteen minutes of transactions and need service back within four hours. For shared folders, losing a day is acceptable and recovery within two days is fine. She learns that objectives come from business needs, not technical preferences, and that they decide backup frequency and the recovery methods needed. The managers sign the agreed objectives, and Aisha checks that current backups can meet them. Core banking backups currently run hourly, so she recommends more frequent copies.
25.4 Recovery plan
Aisha writes a recovery plan listing the order of systems to restore, the steps for each and the people responsible. Core banking comes first because members depend on it, followed by email and then shared folders. She notes dependencies: core banking needs the directory service for logins, so that must be restored before it. Dr. Carrow notes that recovery order is often discovered only during a real crisis if not planned. The IT manager walks through the plan with her and adds two missing steps.
Worked example
Aisha adds an offline copy, tests a restore with fingerprints and finds open-file failures, sets objectives with managers and writes a dependency-aware recovery order.
Synthetic case. Backups are synthetic.
Errors and limits
Backups reachable from the network can be destroyed by ransomware.
Exercises
- EX073 — Missing copy. What extra backup copy does Aisha recommend? Rubric: 3 = offline or immutable copy away from head office;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX074 — Restore failures. Why did some files fail to restore? Rubric: 3 = they were open during backup;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX075 — Core objectives. What are core banking's objectives? Rubric: 3 = fifteen minutes of data, four hours to restore;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 25 (chapter 25 of 40)
← Chapter 24 · Course chapter index · Chapter 26 →
Continue to the next authored lesson.