Bit rot on an external drive

Short answer: record a hash when you write a file, and compare it later. If the hashes differ and nothing edited the file, the bytes changed underneath you.

Nothing else finds this. A disk with silent corruption on it passes First Aid, reports healthy SMART, and mounts perfectly.

What bit rot actually is

Storage is physical. Magnetic domains on a spinning disk weaken. Charge leaks out of the cells in flash memory, faster when it is warm and faster still when the drive sits unpowered for a long time. A cable can drop a bit in transit. Firmware has bugs.

Drives correct most of this themselves, with error-correcting codes and by relocating sectors they find going bad. The corruption that matters is the part that gets past that: a read that returns different bytes from the ones written, and reports success.

The name people argue about. Some call it bit rot, some silent data corruption, some data degradation. They are the same thing for our purposes: the file is different and nothing said so.

Why nothing tells you

This is the part worth understanding, because it explains why every tool you would reach for is the wrong tool.

SMART reports drive health, not file health. It counts reallocated sectors and read errors the drive noticed. A silent corruption is by definition one it did not notice.
Disk Utility First Aid checks the filesystem. It verifies that the structure which maps names to blocks is coherent. It does not know what those blocks are supposed to contain.
APFS checksums metadata, not your data. Apple's filesystem protects its own structures with checksums. The contents of your files are not covered. ZFS and Btrfs do checksum file data, which is exactly why people who care about this run them, and neither is what your Mac or your external drive uses.
Copying does not check. cp and Finder read bytes and write bytes. If the read returned wrong bytes, they faithfully write the wrong bytes.

So the honest position is: your Mac has no mechanism that would tell you. The first symptom is a photo with a band of garbage through it, an archive that will not open, or a video that stops halfway.

How likely is it, really

Rare per file, and not rare across a large collection over a long time, which is the case a backup is for. Two things raise the odds noticeably:

Time and dormancy. A drive written once and put in a drawer for five years is the classic case. Flash in particular loses charge without power.
Heat and age. Both, in the obvious direction.

The reason it matters more in a backup than on your working disk is that a working file gets opened, and an opened corrupt file is a corruption you have discovered. A backup is written once and never read, which means corruption in a backup is discovered on the day you need the backup.

The check, by hand

Record what you wrote:

cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txt

Then, months later, ask whether it is still the same:

cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'

Anything printed is a file whose bytes have changed. If you have not edited it, that is your answer.

Two practical notes. Keep the hash file somewhere other than the drive it describes, or you will lose both together. And this takes as long as reading the whole drive, so schedule it overnight.

Why this is the whole design of Copy Shelter

Everything above is the reason the app exists in the shape it does. It stores every piece of a backup under the hash of its contents, then reads the backup back on a schedule and checks each piece against the hash it was stored under.

A mismatch is therefore proof: the bytes are not the bytes that were written, and there is no interpretation in which that is fine. A piece that has been deleted underneath the backup is reported as missing. And the score on the main screen counts only what has been verified recently, which is why it is lower than people expect and why that is the point.

Having a second location matters more here than anywhere else on this site. Corruption in one copy is an inconvenience when there are two, and it is the end of the file when there is one.

Common questions

Will Disk Utility find this?

No. First Aid checks the filesystem structure, not the contents of your files. A drive with silently corrupted files passes it cleanly, which is exactly what makes this problem what it is.

Does SMART tell me?

Not for this. SMART reports errors the drive noticed and corrected or relocated. Silent corruption is the category it did not notice. Worth checking anyway for a drive that is genuinely failing, which is a different and more visible problem.

Does APFS protect against it?

It checksums its own metadata, not your file data. ZFS and Btrfs checksum file contents and can repair from a redundant copy, and neither is available as a normal macOS boot or external volume. That gap is why an application-level check is worth having.

How often should I verify?

Often enough that a bad copy is found while a good copy still exists. Quarterly is reasonable for an archive; monthly if it is the only copy of something irreplaceable. The right answer is whatever you will actually not skip, which argues for it being automatic.

Is one verified copy enough?

No. Verification tells you a copy has gone bad. It cannot give the file back. Detection is only useful when there is a second copy to restore from, which is the entire argument for the 3-2-1 rule.

Bit rot on an external drive, and how you would ever know