How to check that your Mac backup can actually be restored

This is a guide, not a sales page. It works with whatever you already use, and you do not need to buy anything to follow it.

Why “the backup ran” is not “the backup works”

A backup can run every hour for a year and still be unreadable. A disk flips a bit. An upload truncates. A cloud provider silently drops an object. An exclusion rule you wrote in 2023 quietly swallowed the folder you care about most. None of that shows up in a backup log, because backing up never reads what is already there.

The only way to know is to take files out and look at them. Everything below is that, in four steps.

The test, in one sentence

Step 1 — pick files that would actually hurt to lose

Not one small text file. Pick a folder with some structure to it: nested directories, a large file, a file with an awkward name — an accent, an emoji, a space, an apostrophe. Those are where backup tools break, and a test made of test1.txt will never find it.

Good candidates: a finished client job, last year's accounts, a photo shoot, the folder you would phone someone about at midnight.

Step 2 — restore to a new folder, never in place

Restore into something like ~/Restored. Do not restore over the originals: if the backup is broken, restoring in place is how a bad backup destroys the good copy, and it is the one mistake in this whole exercise that cannot be undone.

Keep the originals exactly where they are. You are about to compare against them.

Step 3 — compare, byte for byte

Open Terminal. Both recipes below are real commands; the second one is the one to use if you want to keep the evidence.

The quick way

Nothing printed means every file is identical.

diff -rq ~/Documents/Client-Work ~/Restored/Client-Work

Add -x .DS_Store to stop the Finder's own bookkeeping files being reported as differences. They are not part of your work and they change constantly.

The thorough way

This one hashes every file on both sides and compares the two lists, which gives you something you can date, keep, and compare against next quarter.

cd ~/Documents/Client-Work
find . -type f -exec shasum -a 256 {} + | sort > /tmp/original.txt

cd ~/Restored/Client-Work
find . -type f -exec shasum -a 256 {} + | sort > /tmp/restored.txt

diff /tmp/original.txt /tmp/restored.txt && echo "Every file matches."

If a file came back wrong, diff prints the hash and the path of both versions, so you know exactly which file failed rather than just that something did.

A caution worth stating plainly: this compares file contents. It does not compare permissions, extended attributes, or resource forks. For most people's documents that is the part that matters — but if you are backing up something where ownership and ACLs are load-bearing, check those separately.

Step 4 — read the date

The other half of the test, and the half people skip. Look at the newest snapshot in your backup and ask when it was made. A backup that restores perfectly and last ran in March is not protecting you; it is protecting the version of you that existed in March.

While you are there, check the size trend too. A backup that suddenly got much smaller usually means something stopped being included.

The four things that are usually wrong

When this test fails, it is nearly always one of these.

Doing this with Time Machine

Time Machine has two built-in commands for exactly this, and almost nobody knows about them. Both descriptions below come from man tmutil on macOS 26.

Compare the backup with your Mac

tmutil compare

With no arguments this compares your computer against the latest backup. There is a catch that matters: the default property set is -@gmstu — extended attributes, group, mode, size, modification time and owner. File contents are not compared by default. To compare the actual data you have to ask for it:

tmutil compare -d ~/Documents/Client-Work /Volumes/…/Backups.backupdb/…/Client-Work

tmutil listbackups prints the paths of your backups to fill in that second argument. Comparing data forks reads every byte on both sides, so point it at a folder rather than your whole home directory the first time.

Check the backup against its own recorded checksums

tmutil verifychecksums /Volumes/…/Backups.backupdb/…/Client-Work

Time Machine has recorded a checksum for each file it copies since OS X 10.11. This recomputes them and reports mismatches with ! and unusable recorded checksums with ?. Silence means everything matched. Note that it verifies against what was recorded at backup time, so it finds a file that rotted in the backup — not a file that was already wrong when it was copied. That is what Step 3 is for.

Restoring with tmutil restore source destination may need Full Disk Access, and root if you want ownership preserved. Restoring through the Time Machine interface is fine too — just aim it at a new folder, per Step 2.

Doing this with restic

Three commands, in increasing order of how much they prove.

restic check

Structural consistency: every snapshot, tree and pack file is accounted for.

restic check --read-data-subset=10%

Downloads a random tenth of the packs and verifies the data against its hashes. This is the check that finds a bit that flipped inside a pack, and the only one of the three that costs bandwidth. Use --read-data for all of it.

restic restore latest --target ~/Restored --include ~/Documents/Client-Work

Then run Step 3 against what came back. That is the whole drill.

Doing this with anything else

The tool does not matter. Use whatever restore feature it has, aim it at ~/Restored, and run Step 3. If your backup software has no way to restore a single folder to a location you choose, that is worth knowing on a quiet Tuesday rather than during an emergency.

How often

Quarterly is a reasonable floor. Monthly if the data is how you earn a living. Always after you change something — a new destination, a new exclusion rule, a macOS upgrade, a new Mac. Those are the moments backups break, and they are also the moments nobody thinks to check.

Write the date down somewhere. “I think I tested it last year” is the same information as “I have never tested it.”

And if you would rather not remember

Backstop does this on a schedule instead of you doing it: a weekly integrity check, a monthly read-back of the stored data, and a monthly restore drill that takes real files out of the backup, puts them back, and compares them byte for byte with the originals — then writes down the result and the date. It is $39 for three Macs.

It is also entirely possible to run the test above by hand forever and never pay us anything, which is why this page tells you how.

---

What Backstop does Restore commands, tested every build