Back to guides

How to check a backup is actually readable

How to check a backup can be restored: how to record what you wrote, check it later, and what silent corruption looks like. Updated September 2026.

Short answer: record a hash of every file when you write the backup, and re-run the check against the backup later.

If the hashes still match, the bytes are still there. Nothing else proves it.

Why a backup rots quietly

Four things go wrong, and none of them announces itself:

All four look identical from the outside: a directory full of files with plausible names and dates.

Checking by hand

When you write the backup, record what you wrote:

find /Volumes/Backup/Documents -type f -exec shasum -a 256 {} + > ~/backup.sha256

Later, ask whether the backup still matches that record:

shasum -a 256 -c ~/backup.sha256

Every line comes back OK or FAILED. A file that has vanished entirely is reported as unreadable, which is the behavior you want: a missing file is a failure, not an absence of evidence.

Keep the hash file somewhere that is not the backup disk. A record stored next to the thing it describes dies with it.

Checking that the backup is recent

Separate question, and the one people get caught by. The newest file in the backup tells you when the job last succeeded:

find /Volumes/Backup -type f -newermt '-7 days' | head

No output means nothing has been written in a week. If you are relying on Time Machine, ask it directly:

tmutil latestbackup

Actually restoring something

Hashes prove the bytes survived. They do not prove you can get a file back out, because that also depends on the tool, the index, the encryption key and your memory of how to use all three. Once or twice a year, restore something real into a scratch folder and open it.

Pick a file you would actually miss, not a test document. The point of the exercise is to find out that your recovery key is on a note in the Mac being backed up, and to find that out on a quiet Tuesday.

What good looks like

An automatic check has three properties the manual version does not: it runs whether or not you remember, it checks every piece including the ones you did not think of, and it tells you the moment it fails.

Copy Shelter reads the backup back and checks every piece against the hash it was stored under, reports a deleted piece as missing, and counts only copies it has actually checked. It also speaks up after 7 days without a backup that worked, which catches the fourth failure above, the common one.

Common questions

Is shasum slow?

It reads every byte, so it takes about as long as copying the data. That is the point: a check that does not read the data cannot detect a disk that fails to return it.

Can I check only some of it?

Yes, and a random sample is much better than nothing. find ... | shuf -n 50 gives you fifty files to check, which will catch a failing disk or a stopped job quickly, though not a single corrupt file.

Does the cloud already do this?

Storage providers checksum their own copies, and that protects you from their disks failing. It does not protect you from an upload that never finished, a file that was already corrupt when you sent it, or a sync that stopped. The check has to happen from your side.

What do I do if a check fails?

Do not overwrite the backup. Take a second copy from your Mac to different storage first, then work out which of the two is wrong. A failed check on a backup you immediately re-run is a failed check you have just destroyed the evidence for.

How often?

Monthly is a reasonable rhythm for a full check, weekly for a sample, and once or twice a year for an actual restore. Anything on a schedule beats anything you have to remember.

Related: the 3-2-1 backup rule, and what people get wrong.

Related guides