Bitrot: Finding the Files That Rot Silently, and What to Do About Them
A rescue of a 2009 media archive from bitrot is a better cautionary tale than any lecture on backups, because the damage was invisible for years. The files opened, the folders listed, the sizes looked right - and a fraction of the bytes underneath had quietly changed. What found it was a hash check, not a human eye.
That is the defining property of bitrot: it does not announce itself. A disk that fails is obvious and repairable. A file that has decayed by four kilobytes in the middle is neither, until the day you need it and the video stops halfway or the document opens to a page of noise.
What actually corrupts a file
| Cause | What it looks like | How it is caught |
|---|---|---|
| Media degradation | A few bad sectors in old files, often ones not read for years | A full read with checksum comparison |
| Power loss during a write | One truncated or half-written file, often the newest | Filesystem journal recovery, then a re-copy |
| Failing cable or controller | Silent corruption in transit, sometimes repeated | Hash the copy and compare with the source |
| RAM or firmware fault | Scattered damage across unrelated files | Repeated verification, then hardware testing |
| Software bug in a sync tool | Old file replaced by a newer, wrong one | Versioned snapshots rather than live sync |
The second row is the one people forget. A copy interrupted by a power cut produces a file that exists, has a plausible size, and is wrong. Without a checksum to compare, nothing in the operating system will tell you.
Building a check you can run in a year
Step 1 Hash the set that matters, once
Use a SHA-256 manifest over the irreplaceable folder. The output is a text file listing a hash per file, and it is the reference every future check compares against.
Step 2 Store the manifest somewhere else
A manifest on the same disk as the data tells you the disk agrees with itself. Keep it in a second location, and keep a dated copy so you can compare across years.
Step 3 Verify after every copy, not after every year
Copy, then verify the destination against the source before you delete anything. This single habit catches the cable, the controller and the interrupted write in the same pass.
Step 4 Use a filesystem or plugin that scrubs
ZFS and btrfs verify checksums on read and can repair from redundancy. Parity-based arrays do not detect corruption by default, which is why a checksum plugin or a separate verification pass is needed there.
Step 5 Re-verify on a schedule you will keep
Once a year is enough for a personal archive. The point is not frequency; it is that a check that never runs catches nothing, and a yearly reminder is a check that runs.
Step 6 When a mismatch appears, replace the copy first
Identify which copy is good, restore from it, and only then investigate the source. Trying to repair the damaged file in place risks overwriting the last good bytes.
Where people think they are protected and are not
- RAID or parity: it survives a dead disk, and it will happily keep a corrupted file consistent across every disk.
- Cloud sync: a sync deletes as faithfully as it copies, so a corrupt local file propagates.
- A second drive in the same room: it protects against one failure, not against a power event that reaches both.
- Torrent reseeding as a backup: the hash check is excellent verification, not a copy strategy.
- "It still opens": a video that plays for two minutes can be broken for the last forty.
- Compression: a damaged archive can lose every file inside it, not just the one that decayed.
Can bitrot be repaired?
Only from another copy. There is no tool that reconstructs missing bytes from nothing; what tools do is detect the damage, and what redundancy does is supply a good copy. This is why verification and duplication are the same project.
Does a parity drive protect against corruption?
It protects against a disk disappearing, not against a bit changing. In a parity array the corrupted file is part of the parity calculation, so the array preserves the damage. Checksums on the filesystem, or a verification plugin, are what make the difference visible.
How often should I verify an archive?
Yearly for most personal collections, and after every migration to new media. Verification is a read pass, so it also surfaces a drive that is starting to fail while you still have time to act.
Is a cloud provider immune to this?
No, but large providers run their own checksums and redundancy. Your risk moves from media decay to the account itself - a billing failure, a policy change or a closed account - which is why the off-site copy should not be only a cloud account.
💡Protip:
When a drive has already begun to fail and you need the files off it before it dies, Dr.Fone - Data Recovery can help scan a device you own for recoverable data.
🔍More Info:
1. Personal Archiving Done Right: Storing Old Media for Decades2. Self-Hosted Archiving at Scale Without Losing Track
3. Protecting a Self-Hosted Media Library
4. Compress, Archive or Delete: A Storage Decision Guide
