How to check whether your backup would actually restore

The four ways backups fail

Almost every backup that fails does so in one of these four ways, and none of them announce themselves.

It stopped running. The scheduled task fails, the external drive was not plugged in, credentials expired, the service was updated and the job did not survive. The last successful run was in March and nothing said so.

It runs and copies nothing. The source path changed — a folder renamed, a drive letter reassigned, a user account migrated — and the job now backs up an empty directory very quickly and reports success.

It only exists in one place. One copy, on a drive that sits next to the computer. That covers a deleted file and a failed disk. It does not cover theft, fire, flood, a power surge, or ransomware that encrypts every drive it can reach — including the backup one.

It is not restorable. The files are there and the archive is corrupt, or the software that wrote it is gone, or the encryption key was on the machine that died.

Check one: restore something

This is the only check that is not a proxy for something else, and it is the one to do first.

Pick a file you know — not a random one, one whose contents you can verify. Restore it to a scratch folder. Then compare it against the original properly:

shasum -a 256 original.pdf restored.pdf     # macOS / Linux

Get-FileHash original.pdf, restored.pdf     # Windows PowerShell

Two identical hashes means that file came back exactly. Do this once a quarter and put it in the calendar. Almost nobody does, and it is the single highest-value thing on this page.

Check two: count the copies, per file

“I have a backup” is a statement about a job. What matters is a statement about a file.

The old rule is 3-2-1: three copies of anything you care about, on two different kinds of media, with one of them somewhere else. It is a good rule and it is worth applying literally rather than approximately — go file by file and ask how many good copies exist, on how many distinct devices, and whether any of them is offsite.

Done properly, this almost always turns up a folder that everybody assumed was covered and is not. New projects created after the backup job was set up are the usual culprit.

Check three: when did it last succeed?

Not “is it configured” — when did it last actually finish. And has its output suddenly got smaller, because a job that used to write 40 GB and now writes 200 MB is a job whose source path is wrong.

If you look after more than one machine, this is the check that matters most and it needs a record: one line appended per run, per job, so you can ask on any given day which jobs have not succeeded within the window you promised.

Check four: the restore path itself

Write down, on paper or somewhere that is not the machine being backed up:

• Where the backups are, and what reads them.
• The password or key, and where a second copy of it lives.
• Roughly how long a full restore takes. If the answer is “four days over that broadband connection”, you have a different plan to make.

An encrypted backup whose key was only ever on the dead laptop is not a backup.

The programs for this

• SafeMirror does check two. It does not make backups — it audits the ones you already have, and answers per file how many good copies exist, on how many distinct media, and whether any copy is offsite. Then it names every file that breaks the rule.
• BackupMedic does check three across a fleet. Jobs append one record per run to a shared history file; it reports for every machine and job when it last succeeded, whether that is inside the recovery window you promised, whether it is failing silently, and whether its output has suddenly shrunk.
• RescueVault makes the backups: timestamped snapshots you can browse as ordinary folders, where files unchanged since the last snapshot are hardlinked rather than copied, so unchanged data costs no extra disk. Every command is a dry run unless you pass --apply.
• RestoreGuard is the same thing with a retention policy: everything from the last day, one per day for the last week, one per week for the last month.

Free while we are in preview, one file each, Windows and Mac.

The one that catches people out

Ransomware. A backup drive that is permanently mounted is a drive that gets encrypted along with everything else, and cloud sync is not a backup — it faithfully replicates the encryption to every copy within minutes.

What survives it is a copy that was not connected when it happened. A drive you unplug, or snapshots on a system that will not let anything overwrite them. That is what the “1” in 3-2-1 is really for.