The 3-2-1 rule, and a restore you have actually tested

Why this matters

The previous lesson covered what backups are and how they are made. This one is about whether they work, and the honest position is that a large proportion do not. Not because the software fails — although it does — but because nobody ever tried to restore, and a backup that has never been restored is an assumption rather than a protection.

The 3-2-1 rule is the exam's summary of a sensible position, and each number in it defends against a specific failure. The testing half gets less attention and is where the real failures are, which is why it takes up most of this lesson.

The lesson

Three copies, two media, one off-site, and what each number is defending against

Three copies, on two different media, with one off site. Each number answers a question.

Three copies — the live data plus two backups. Why two rather than one: because backups fail. Media degrades, a disk dies, a backup job silently stops, a file is corrupt. One backup means one thing standing between you and loss, and the probability of it being unusable on the day is much higher than people assume.

Two different media — not two copies on the same kind of thing. Two external disks of the same model bought together share a failure mode and sometimes a manufacturing batch. Disk and cloud, disk and tape, local and remote: different technology, different failure modes, different operators.

One off site — because fire, flood and theft take everything in the building. This is the number most often skipped, because it is the inconvenient one. Cloud backup satisfies it automatically, which is the main reason it has become the default answer.

The modern extension, worth knowing because it appears in current guidance: 3-2-1-1-0 — one copy offline or immutable, and zero errors on verification. Those two additions are exactly the ransomware lesson and the testing lesson respectively, which is a reasonable summary of what changed.

Applied to one person with a laptop: the live data, a backup on an external disk, and a cloud backup. Three copies, two media, one off site. It costs very little and it covers every risk in the previous lesson.

The untested backup, which is the most common failure in this whole objective

This is the single most common failure in this objective, and it has a consistent shape.

The backup job runs nightly. The console is green. Nobody has ever restored anything. Then something is needed and one of these turns out to be true:

• The job has been failing for four months and the notification went to a mailbox nobody reads.
• It was backing up the wrong folder. The user's data was in a location the job never covered — a second drive, a mail store, a profile folder outside the selection.
• The backup is encrypted and nobody has the key, or the key was on the machine that died.
• The archive is corrupt, and there is no way to know that without opening it.
• The restore needs software or a licence that only existed on the dead machine.
• The restore works and takes four days, which nobody knew.
• The backup contains the ransomware, because it started weeks before anyone noticed.

None of those is detectable from the backup console. Every one of them is detectable by restoring something.

So the rule is: a backup is not a backup until it has been restored. Until then it is an assumption with a progress bar, and the moment it is disproved is always the worst possible moment.

The second rule follows: someone has to look at the results. A job that alerts on failure to an address nobody monitors has no alerting. A weekly glance at the backup report is a real control, and it takes a minute.

Testing a restore properly: a file, a folder, and a whole machine

Testing a restore properly means three different tests, because they prove different things.

A single file. Weekly or monthly, restore one file to a different location and open it. This proves the backup is readable, the restore process works, the credentials are current, and the content is intact. It takes two minutes and catches most of the failures in the previous section.

A folder, to an alternative location. Quarterly. This proves that a meaningful quantity restores, that permissions and structure come back, and that it does not take unexpectedly long. Restoring to an alternative location rather than over the original is the safe habit: an in-place restore of a large folder can destroy current work if anything is wrong.

A whole machine. Annually at least, and after any significant change to the backup arrangement. Restore to spare hardware or to a virtual machine. This is the only test that proves:

• the backup contains everything needed to boot;
• the restore media and the recovery tool work;
• the drivers work on different hardware, where that matters;
• the encryption keys are available;
• anyone other than the person who set it up can perform it;
• how long it actually takes.

Record each test: what was restored, when, how long, and anything that went wrong. That record is what makes the recovery figures in the next section real numbers rather than hopes.

Recovery time and recovery point, explained without the consultancy vocabulary

Two terms, without the consultancy framing.

Recovery point objective — how much work you are willing to lose. It is answered by how often the backup runs. A nightly backup means a recovery point of up to twenty-four hours: a failure at 4pm loses a day's work. Continuous protection means minutes.

The question for a user is: "if this machine died right now, how much of today's work could you bear to redo?" The answer sets the frequency, and the answer is often "nothing at all", which means the nightly backup is the wrong design and the fix is usually cloud sync with versioning alongside it.

Recovery time objective — how long you are willing to be without it. It is answered by the restore process, the size of the data, and the speed of the destination. A two-terabyte cloud restore over a domestic connection is days.

The question is: "how long can you manage with this not working before it becomes a serious problem?" If the answer is four hours and the tested restore takes two days, there is a gap, and it is resolved by changing the design — a local copy for speed, an image rather than a file backup, spare hardware ready — rather than by writing a smaller number down.

Why both matter to a technician: these two numbers turn "we should back up more often" into a specific decision somebody can approve. And the recovery time is only real if it has been measured, which is what the whole-machine test in the previous section produces.

Documenting the restore procedure so someone else can run it under pressure

The restore is performed on the worst day, by someone who may not be you, under pressure, possibly without the machine that held the instructions.

What the procedure must contain:

• Where the backups are, all of them, with addresses and names.
• What credentials are needed, and where they are stored — in the password manager, in a sealed envelope, with a named person. Not on the machine being restored.
• Encryption keys and their location, which is the most common single point of failure in a documented restore.
• The software needed, its version, and how to obtain it — including a licence key if it needs one.
• Step-by-step instructions, numbered, specific, with exact values.
• How long each stage takes, from the tests.
• How to verify the restore worked.
• Who to call if it does not.

Where it lives: not only on the network being restored. Printed, and in a location accessible when the estate is down — which is the scenario, after all. A restore procedure stored exclusively in the encrypted file server is a very common and entirely predictable failure.

Who should be able to run it: somebody other than its author, and the way to establish that is to have them do the annual whole-machine test. If they cannot follow it without asking questions, the gaps are in the steps the author does automatically.

Keep it current as part of any change to the backup arrangement, which is the change management lesson applying to the thing that protects everything else.