How to verify a backup on Mac
Backup software reports on the job it ran, not on the files it left behind afterwards. The only way to know a copy is still intact years later is to have written down what it looked like while it was good: Rocket Hash will record that for a whole archive in one pass, and hold the copy to it whenever you come back to it.
There is a disk in a drawer with eleven years of photographs on it, or a project archive on a NAS that was last written to in 2022. Nothing has reported a problem. Nothing has reported anything at all, because nothing has read those files since the day they were written — and a backup nobody has read is a backup nobody has tested.
The uncomfortable part is when you find out. Damage in an archive is discovered on the afternoon you go looking for one particular thing — the afternoon you least want to learn that the copy is bad and the original went years ago.
Hashing turns that into something you can check on a Tuesday instead. Record a fingerprint for every file while you still trust it, keep the list, and re-run it against the copy whenever you like: any file whose bytes have shifted since names itself. This page is about that loop — what to fingerprint, where to keep the list, and how to tell a file that rotted from a file you edited and forgot about.
A manifest stored only on the backup drive is checked by the hardware it is meant to be checking, and lost in the same accident. Keep a copy anywhere that is not the thing under test.
The two questions people mean by “verify”
“Is my backup good?” is two questions wearing one coat, and only one of them is what this page is for.
- Did the copy arrive correctly? A one-off question, asked at the moment of copying, answered by comparing the two copies while both still exist. That is verifying a file after a transfer, and it is the question this page assumes you already answered.
- Is it still correct now? Asked repeatedly, months or years later, when the original may be long gone. This needs something recorded in the past to compare against, which is what a manifest is for. It is the subject of this page.
What actually goes wrong with an old backup
Cosmic rays are the romantic explanation and almost never the real one: drives have error-correcting codes, and an unreadable sector is usually reported as an error rather than returned as plausible nonsense. The things that genuinely eat archives are duller:
- The file was already wrong when it was copied. By far the most common cause, and the reason the fingerprint has to come from the source rather than from the backup.
- A backup run that stopped half way. Interrupted jobs leave short files, and a short file is a perfectly valid file as far as the filesystem is concerned.
- Sync, not backup. A folder that mirrors another folder faithfully propagates a truncation, an accidental overwrite or a deletion. Mirroring is not history.
- Media with a shelf life. Charge leaks out of flash cells that are never refreshed, which makes an SSD in a drawer a worse long-term archive than a hard disk in a drawer. Writable discs and old tape decay too.
- Filesystem damage. A volume unplugged mid-write, or a controller that failed during a remap, leaves files readable and wrong.
One detail worth having: APFS computes checksums over its own metadata, not over the contents of your files. The filesystem is protecting its bookkeeping, not your photographs. ZFS and Btrfs do checksum user data, which is why they can scrub themselves and why on a Mac you keep the list yourself.
Record the fingerprints while the originals are good
The order of operations is the whole trick. A manifest generated from the backup tells you only what the backup looked like on the day you generated it, including any damage already baked in. Generate it from the source, at the moment you believe the source is right, and it becomes a statement you can hold the copy to forever. The Files tool in Rocket Hash is shaped for that job — a hundred thousand files in one queue, streamed in a single pass, exported as a list at the end.
-
Hash the originals, not the copy
Drop the source folder into Files and let it walk everything underneath. Hashing only ever reads, so it is safe to point at master material — nothing is written, no modification date moves, nothing is reorganized. Hashing a whole folder covers what a folder run produces, and whether hashing changes a file settles the question if it is nagging at you.
-
Pick one algorithm and keep it
Set the Algorithm control to SHA-256 and leave it there for the rest of your life. A manifest is only checkable by the same function that produced it, so consistency across years matters far more than any argument about which algorithm is best. SHA-256 is also what every other tool assumes when a list of 64-character digests turns up.
-
Export the manifest and put the date in the name
Use the export control when the run finishes. What comes out is a plain two-column list — the digest, two spaces, the path — which is the format checksum files have used for thirty years, so anything that reads one will read yours. Name it for what and when:
photos-2026-09.txtbeatsmanifest.txtthe first time you have two of them. Exporting a manifest has the specifics, and the format of a SHA256SUMS file explains the columns. -
Store the list away from the data
Keep it on your Mac, commit it to a repository, put it beside the disk inventory — anywhere that does not share a failure with the drive it describes. A manifest is a few megabytes for tens of thousands of files, so there is no excuse for having only one.
-
Re-check the copy on a schedule
Once a year for cold archives, once a quarter for anything you would grieve over. Put it in the calendar, not in your intentions, and note the date of each clean check beside the manifest, so a failure next year has a known-good date behind it. The point of a schedule is that damage is found while a second copy still exists.
Checking the backup months later
The check is the first run again, pointed at the copy instead of the source. Mount the drive, drop the backup folder into Files, set the Algorithm control to match the old list, and let it read — pausing mid-file and resuming from the same byte when you want the machine back. Export at the end with today's date in the name, and you have two lists describing the same folder a year apart.
Two lists of forty thousand lines are not something to read; they are something to line up. The digest is the first column of every row, so matching rows stack up and a file whose bytes have moved is the row that does not. Checking files against a manifest covers putting the two side by side and what each kind of difference means.
For the few files you care about most there is a shorter route that skips the lists. Open Verify, leave the segmented control on Against a Checksum, add the file from the backup and paste its digest out of the old list: the answer is a green seal and a sentence, and the algorithm is detected from the checksum itself. If the original is still on the machine, File vs. File settles it from the two copies with no list in the middle.
Telling rot apart from your own edits
The first time you check a working folder against a six-month-old manifest, dozens of files fail and every one is your own work. That is not a false positive — the bytes really did change — but it is noise, and noise is what stops people running the check at all.
The fix is to sort your data by whether it is supposed to change, and only manifest the half that is not.
| Material | Changes? | Worth a manifest |
|---|---|---|
| Camera originals, scans, finished exports | Never | Yes — any change is damage |
| Delivered projects, closed jobs, tax records | Never, after the date | Yes — one manifest per job, at hand-off |
| Working documents, code, notes | Constantly | No — use version control or snapshots |
| Databases and mail stores | While open | No — hash an exported dump instead |
For anything in the last two rows, a digest taken while the file was being written describes a state that never quite existed on disk; hashing a file that is still changing covers why. Keep a dated manifest per archive rather than one growing list for everything, and a failure becomes unambiguous: nobody was supposed to touch that folder, so something did.
The temptation when a single file fails is to regenerate the list so it comes out clean. That repairs nothing — it records the damage as the new truth and throws away your only evidence. Restore the file from another copy, then re-check against the original list.
What a manifest cannot do for you
Three honest limits, because a verification habit built on a misunderstanding is worse than none at all.
It does not work inside an opaque backup. If the backup is one large container — a sparse bundle, an encrypted image, a proprietary archive — the files inside are out of reach, and a digest of the container is close to useless, because every routine change rewrites it. Keep one copy of anything irreplaceable as plain files on a plain filesystem; that is the copy you can verify, and only a test restore says anything about the rest.
It cannot reach a cloud backup without a download. Hashing needs the bytes, so a remote service can only be checked by pulling the file back. Treat any checksum a provider shows you as their claim about their own copy: useful, not independent.
It repairs nothing. A digest is a smoke alarm, not a sprinkler. Detection is only worth something when you have somewhere to restore from, so two copies and a list beat three copies and a hope.
Troubleshooting
One file fails and everything else passes
That is a damaged file rather than a failing disk, and it is the best version of this news: you know which file, and you found out while another copy may still exist. Restore it, re-run the check, and note the date — if a second file fails next quarter, the pattern is the drive.
Every single file fails
Two failures look alike and mean opposite things. If the new list barely overlaps the old one — different paths, or far fewer of them — you hashed the wrong folder: paths are recorded relative to the folder you dropped in, so a run started one level up lines up with nothing. If the paths match and every digest differs, the bytes really are different, and you are almost certainly comparing two generations of the same archive: a list made before one last round of edits, or a folder something has re-exported since. Hardware does not fail everywhere at once.
A manifest of SHA-3 digests fails on every line
This is the trap worth knowing about before you choose an algorithm. A SHA3-256 digest is 64 characters long, exactly like a SHA-256 one, and nothing can tell them apart by looking — so a value that gets identified from the checksum alone is read as SHA-256, and SHA-3 and SHA-2 are entirely different functions. Every line fails, with nothing on screen to hint at why. CRC32 at least fails honestly: eight characters match no length anything expects. Keep archive manifests in SHA-256, note the algorithm in the file name if you ever stray, and the ambiguity never comes up.
The check says files are missing
A manifest records names and paths as well as digests, so a file that has been renamed, reorganized into a different subfolder or simply not copied reads as missing rather than as changed. Missing is a finding too — it is how you discover the subfolder that never made it into the backup. If the reorganization was deliberate, compare the digest columns of two manifests instead of checking paths, and see finding duplicates by hash for the technique.
The run takes all night
It might reasonably. Two terabytes from a USB hard disk at around 130 MB/s is roughly four hours of solid reading, and a hundred thousand small files are slower than the same bytes in one large one, because each costs an open and a close. The arithmetic is not what you are waiting for: SHA-256 runs at roughly 2 GB/s on Apple Silicon. Start the run when you stop working, or pause it mid-file and pick up from the same byte later.
The disk has not been powered on in two years
Power it on today, and then once a year. Two years of silence is not evidence of health — a drive that never spins up never gets the chance to report anything, and the annual read may as well be the verification run.
Frequently asked questions
How do I know if my backup is actually working?
Read it back and compare it with something recorded earlier — that is the only test that counts. Fingerprint the originals while you trust them, keep the list somewhere other than the backup drive, and re-run it against the copy periodically. A backup that has never been read since it was written is untested, however green the backup app’s status light is.
What is bit rot, and does it really happen on a Mac?
Bit rot is data decaying in place without anything reporting an error: charge leaking out of unpowered flash cells, an aging optical disc, a sector that was remapped badly. It is real but rarer than the boring causes — an interrupted backup run, a file that was already damaged when it was copied, or a sync that faithfully mirrored a mistake. A manifest catches all of them the same way, because all of them change the bytes.
How often should I verify a backup?
Once a year is enough for cold archives that never change, and once a quarter is sensible for anything whose loss would genuinely hurt. The schedule matters less than the fact that each check happens while a second copy still exists — detection is only valuable if there is something to restore from.
Can I verify a Time Machine backup with a checksum?
Not file by file, if the backup lives inside a single container such as a sparse bundle or an encrypted image. You cannot reach the files from outside it, and hashing the container as a whole is useless because every ordinary change rewrites it. The practical answer is to keep one copy of irreplaceable material as plain files on a plain volume, and verify that copy.
Which algorithm should I use for a backup manifest?
SHA-256, and then never change it — a manifest is only checkable by the function that produced it, so switching later means re-hashing everything. MD5 is faster in principle, but for a backup the disk is the bottleneck rather than the arithmetic, so the speed saving is close to nothing and you lose compatibility with every tool that assumes 64 characters.
Does verifying a backup wear out the drive?
No in any way worth worrying about. Verification only reads, and flash wear comes from writes, not reads. A spinning disk would far rather be read once a year than sit unpowered for five — regular reads are how a drive gets the chance to report a problem while you can still act on it.
Where should I keep the checksum manifest?
Anywhere that does not fail at the same time as the disk it describes: your Mac, a code repository, a second archive drive, or all three. A manifest is tiny next to the data it covers, so there is no reason to have only one copy — and a list stored solely on the backup it is meant to be testing is checking the hardware with itself.