Backups: how to check yours actually work

Almost every organisation has backups. Very few have checked that they restore. The gap between the two shows up exactly once, and it is on the wrong day.

This article sets out a one-hour test, doable without interrupting anything, that turns an intention into a certainty. If you take away one thing: a backup whose contents nobody has ever restored is not a backup. It is a file you are hoping something about.

The day it happens

The sequence is ordinary. An essential file disappears — deleted by mistake, overwritten by an import, made unreadable by a disk failure or by ransomware. You look for the backup. It exists: the vendor set it up, the light has been green for months.

Then you discover one of four things, in varying order. The backup stops at a date earlier than you believed, because a job has been failing silently for six weeks. It contains the files but not the database. It sits on the same server as what it backs up, and went down with it. Or it is complete and restorable, but nobody knows how, and you learn the procedure on a crisis day.

None of these four cases is rare. All of them can be detected in advance, in an hour.

The 3-2-1 rule, and the reason behind each number

Three copies, on two different media, one of them off site. The formula circulates everywhere; what circulates less is why each term is there.

• Three copies — the original plus two backups. Only two means a failure during the restore leaves you with nothing: and a restore is precisely when hardware is under strain.
• Two different media — because failures often correlate with the type of medium. Two disks of the same model, bought together, age together.
• One copy off site — because a fire, a flood or a theft takes everything in one place, however many copies are there.

A fourth requirement has since become necessary: at least one disconnected copy, that no machine can write to. We return to it below.

The three questions to ask

Of your vendor, or of whoever handles this internally. None requires technical knowledge.

1. How often, and what is lost between two backups? A daily backup means an incident at 5 p.m. costs the working day. That may be acceptable — but it should be a decision, not a discovery.
2. Over what depth of history? If only the latest copy is kept, a file corrupted three weeks ago has been backed up corrupted twenty-one times. Depth protects against the mistakes you do not notice immediately.
3. Who has already restored, and when? The only question that truly counts. If the answer is “nobody”, you now know the real state of the arrangement.

The dry-run restore

This is the core of the exercise, and it carries no risk provided one rule holds: never restore onto the original system. The test must not be able to cause the incident it prevents.

1. Choose

Take an old backup, not yesterday's: two or three weeks back. That way you test the depth of history at the same time.

2. Isolate

A test server, a virtual machine, a dedicated workstation. Nothing that talks to production.

3. Restore

Follow the written procedure. If none exists, that is the test's first result — and you should write it while discovering it calmly, not during an outage.

4. Verify, with data you know

The step most often rushed. A restore that “completes without error” proves nothing: it may have produced an empty database. Compare what is checkable — the number of records per table, the presence of one specific customer file, opening a document you can identify. Actually open the files: an archive that decompresses can hold unreadable content.

5. Record

The date of the test, how long it took, what got stuck. The time measured here is the most useful figure in the whole exercise: it is your real downtime, the one you will be asked to announce when the day comes.

What a backup does not protect

Ransomware reaching your network encrypts whatever it can write to — including connected backup disks and synchronised cloud folders. A backup permanently reachable from the machine it backs up is no protection against that case, whatever its size.

Hence the offline copy: a medium physically unplugged between backups, or remote write-once storage that nothing can alter afterwards. It is the only copy left standing when everything else falls together.

A permanently connected backup protects against a disk that breaks. It does not protect against someone who gets in.

How often to retest

A sustainable cadence beats an ideal one abandoned within a month. Twice a year, in the calendar with a named owner, is enough for most organisations — plus one extra test after any change of server, host or backup software, because that is where arrangements break silently.

Add an alert on failure. Without it, a job that stops running does not announce itself: silence looks exactly like everything working.

What you will know at the end

Three things you probably did not: how long a restore actually takes, how much work you lose at worst, and who in your organisation can perform the operation. Those three answers are worth more than the size of your archives.

Our Cybersecurity and DevOps & Cloud pages cover protecting and automating these arrangements respectively. The test above needs nobody but you.