Appearance
Bit rot is the silent, gradual corruption of stored files — bits quietly flipping over the years until a document, image or dataset no longer opens correctly. You cannot stop the underlying physics, but you can defeat its effects with two simple practices: fixity (checksums to detect corruption) and redundancy (multiple copies so you can replace a rotted file). This guide walks a complete beginner through both, with a small example you can run today.
What is bit rot, really?
Storage media are not permanent. Magnetic charge on a hard drive weakens, flash cells leak, optical dye fades, and a stray cosmic ray can flip a bit in memory. The result is "silent" corruption: the file system reports no error, the file still has the same name and size, but its contents have changed by a few bytes. For a JPEG that might be a smear of colour; for a database or a ZIP it can mean the whole file refuses to open.
How do I know if a file has rotted?
You give each file a fingerprint when it is healthy, then check that the fingerprint still matches later. That fingerprint is a checksum (or hash). The same input always produces the same hash; change one bit and the hash changes completely.
bash
# Make a fingerprint of every file, today
find . -type f -print0 | xargs -0 sha256sum > manifest.sha256
# Months later, verify nothing has silently changed
sha256sum -c manifest.sha256If sha256sum -c prints OK for every line, your files are intact. If it prints FAILED for one you never edited, that file has rotted — and now you know.
A small worked example you can follow
Try it on a throwaway folder to see detection in action.
bash
echo "my precious archive" > photo.txt
sha256sum photo.txt > manifest.sha256
# Simulate rot by changing one character
printf 'X' | dd of=photo.txt bs=1 seek=3 conv=notrunc count=1
sha256sum -c manifest.sha256
# -> photo.txt: FAILEDThat FAILED is exactly the alarm you want from a real archive years from now. The lesson: without the manifest, this change would have been invisible.
Detection isn't enough — how do I actually prevent loss?
A checksum tells you a file is broken; it cannot un-break it. Prevention means having a clean copy to restore from. Combine three habits:
| Habit | What it does | Beginner tool |
|---|---|---|
| Fixity | Detects rot | sha256sum, md5deep, Fixity by AVP |
| Redundancy | Lets you replace rotted files | 3-2-1 copies |
| Self-healing storage | Auto-repairs bad blocks | ZFS, Btrfs |
When a fixity check fails, your recovery is simply: copy the good version from another location over the bad one, then re-verify. No clever repair needed — just a spare copy and a manifest.
Should I use self-healing file systems?
If you are comfortable with a bit more setup, file systems like ZFS and Btrfs store checksums for every block and can automatically repair a bad block from a redundant copy during a "scrub." A weekly scrub turns bit-rot detection-and-repair into a background chore:
bash
# ZFS: read every block, verify checksums, auto-repair from redundancy
zpool scrub archivepool
zpool status archivepool # shows repaired errors, if anyThis is the closest thing to true prevention on a single machine — but it still does not replace having an off-site copy.
How often should I check, and what do I do when it fails?
For a home archive, schedule a verification every six to twelve months. For an institution, monthly or quarterly is common. The routine is always the same:
- Run the fixity check against your manifest.
- For any
FAILEDfile, restore the good copy from another location. - Re-run the check to confirm the repair.
- Log the event (what failed, when, how it was fixed) so patterns of failing hardware become visible.
A failing drive often announces itself as a cluster of fixity failures — your log turns silent decay into an early warning.
Key Takeaways
- Bit rot is silent corruption caused by decaying media and random bit flips; the OS won't warn you.
- Checksums (SHA-256) detect rot by comparing a file's fingerprint over time.
- Detection alone can't repair files — you need redundant copies to restore from.
- Combine fixity, 3-2-1 redundancy and optionally self-healing storage (ZFS/Btrfs).
- Run verification on a fixed schedule and act on every failure.
- Always log fixity events so a failing drive reveals itself early.
- Keep your own manifests even in the cloud; the provider protects bytes, not your sync logic.
Frequently Asked Questions
What is bit rot in simple terms?
Bit rot is the slow, silent corruption of stored data: individual bits flip from 0 to 1 or vice versa over time due to media decay, cosmic rays or hardware faults, often without any error being reported.
How do I detect bit rot?
Generate a checksum (a fingerprint such as SHA-256) for each file when you store it, then re-calculate and compare it later. If the checksum changes but you never edited the file, that file has rotted.
Can bit rot be repaired?
Not the corrupted file itself, but you can restore a good copy from another location if you kept multiple copies. That is why detection plus redundancy together solve the problem, not detection alone.
Do checksums prevent bit rot or just detect it?
Checksums only detect it. Prevention comes from redundancy (multiple copies) and self-healing storage like ZFS or Btrfs that can repair a bad block from a good one automatically.
How often should I run fixity checks?
For a small personal archive, once or twice a year is reasonable; institutions often check monthly or quarterly. The key is to do it on a schedule and act on failures, not to do it once and forget.
Does cloud storage suffer from bit rot?
The underlying disks can, but reputable providers run continuous internal checksumming and repair, so visible rot is rare. You should still keep your own manifests and verify, because the provider protects bytes, not your ability to detect a bad sync.