What Bit Rot Actually Is (and What Actually Catches It)

“Bit rot” sounds like a figure of speech, something a forum post exaggerates for effect. It isn’t. It’s a specific, physically real phenomenon, it has been measured at scale by users who work with storage at scale, and there’s a good reason your drive doesn’t warn you about it. Here’s what’s actually happening, how often it actually happens, and what it takes to catch it.

What bit rot actually means

Bit rot, also called silent corruption or data degradation, is data changing on a storage device with nothing to blame it on. No deletion, no drive failure, no user mistake. A file that was fine yesterday has a few bytes that are different today, and nothing in the system logged an error when it happened.

That “silent” part is what makes it a different problem from the failures people already plan around. A dead drive announces itself. A few flipped bits inside a 10-year-old family photo do not.

Where the bits actually come from

Two different pieces of hardware, two different reasons this happens.

Hard drives store data as magnetic orientation, and that orientation isn’t perfectly permanent. Each bit is written across a small cluster of magnetic grains, and as manufacturers pack data more densely, those grains get smaller. Below a certain size, ordinary heat energy in the drive becomes enough to randomly flip a grain’s orientation on its own, a phenomenon physicists call the superparamagnetic effect. It’s the same reason drive vendors quote data retention in years rather than “forever”: magnetic storage is durable, not immortal, and heat is quietly working against it the entire time the drive exists, powered or not.

SSDs fail for a completely different reason. Flash memory stores each bit as a tiny trapped electrical charge inside an insulated cell. Over time, especially when a drive sits unpowered, some of that charge leaks out through the insulation. Enough leakage and the cell’s voltage drifts into ambiguous territory, and a read that used to come back as a 1 starts coming back as a 0. This is also why an SSD you haven’t touched in a year is at more risk than one you use daily. The wear happens whether you’re using the drive or not.

On top of both of those, ordinary things go wrong too: a marginal SATA cable, a flaky controller, a firmware bug in the drive itself. None of it requires anything as dramatic as a head crash to leave a handful of wrong bytes behind.

Why your drive doesn’t tell you

Here’s the part that’s easy to get wrong, and worth being precise about: drives aren’t running a constant background check on the data sitting on them. Both HDDs and SSDs store error-correcting code alongside your data, extra bits that let the drive detect and fix small errors, but that correction only happens at the moment something is actually read back. It’s a read-time safety net, not an ongoing patrol of data that’s just sitting there. A file nobody opens for two years gets zero checks in those two years. Whatever quiet decay happened to it during that time is only discovered, and only correctable up to a point, the next time something actually tries to read it.

Some enterprise storage does go further: RAID controllers on server-grade hardware can run a feature usually called “patrol read” or “background media scan,” which proactively re-reads every sector on a schedule specifically to catch this kind of decay early. It’s a real, well-established feature. It’s also not something an ordinary consumer drive does on its own, and not something most people have sitting under their desk.

Put those two things together and the gap is obvious: nothing is watching a file that nobody happens to open. If enough correctable-level decay accumulates before the next read, whether that read comes from you opening the file or from a backup job copying it, the drive hands back whatever bytes it has. No SMART warning fires, because as far as the drive’s health metrics are concerned, nothing about the drive’s mechanical condition changed. The file just quietly comes back different than it used to be.

How much this actually happens

This isn’t a hypothetical. A few of the more rigorous attempts to measure it:

CERN ran a five-week experiment across more than 3,000 storage nodes, writing a 2 GB test file to each one repeatedly and reading it back to check for mismatches. They found roughly 1.9×10^8 bytes of silent corruption out of 9.7×10^16 bytes written, about one permanently corrupted byte for every ten quadrillion bits, small as a percentage, but CERN’s storage volume at the time meant that rate still added up to hundreds of real, distinct corruption events.

A separate, larger study out of NetApp examined 1.53 million disk drives in production storage systems over 41 months and logged more than 400,000 instances of checksum mismatches, meaning cases where a block’s stored checksum no longer matched its actual contents.

SSDs get their own version of this problem. A large-scale field study covering millions of drive-days across multiple flash technologies found that SSDs consistently produce uncorrectable errors before they ever reach their rated endurance limit, meaning “the drive hasn’t worn out yet” and “the drive has never silently corrupted a file” turned out not to be the same claim.

None of these numbers describe a rare edge case. They describe something that happens continuously, at small scale, everywhere storage exists, including the drive sitting in your desktop right now.

How the people who take this seriously actually solve it

There’s already a well-established, correct answer to this problem, and it isn’t new. Filesystems built for this, ZFS and Btrfs being the two most common examples, write a checksum alongside every single block of data they store. On a regular schedule (or on every read, depending on configuration), the filesystem recomputes each block’s checksum and compares it to the stored value. A mismatch means the data changed since it was written, and the filesystem knows immediately, not whenever a human happens to reopen that file. Pair this with any kind of redundancy and the filesystem can often repair the block automatically from a good copy.

This works. It’s also not something most people are running. It typically means reformatting a drive into a specific filesystem, often paired with a specific OS or NAS platform, which is a bigger commitment than most people backing up a photo library or a project archive are looking to make.

What FileGriffon does instead

FileGriffon applies the same underlying idea, hash it, remember the hash, check it again later, without asking you to change your filesystem at all. It runs as a background service on top of an ordinary NTFS drive.

When you add a folder or drive as a vault, every file gets hashed with XXH3-64, a fast, collision-resistant hash algorithm. A two-pass approach keeps this efficient: a quick partial hash covers the first chunk of a file for routine checks, and a full hash of the entire file runs when something needs a closer look. On whatever schedule you set, FileGriffon rescans the vault, recomputes those hashes, and compares them against what it recorded before. A file whose contents changed outside of a normal edit gets flagged as CORRUPT on the dashboard, not discovered six months later when you actually need that file. Where PAR2 parity protection is enabled for a vault, some corruption can be repaired automatically from the parity data, no different in spirit from how a redundant filesystem repairs a bad block, just running on storage you already have.

What this doesn’t do

Worth being direct about the limits, since overselling this would defeat the point of writing an accurate post about it. FileGriffon isn’t a backup, and it doesn’t replace having one. It isn’t real-time in the way a checksumming filesystem is; corruption gets caught on the next scheduled scan, not the instant it occurs. And parity repair has real limits of its own, it can’t recover a file if there isn’t enough intact parity data to work with, or if the file’s size itself has changed.

What it does do is close the specific gap an earlier post on the 3-2-1 backup rule left open: 3-2-1 tells you how many copies of a file to keep and where to keep them. Nothing about that rule tells you whether those copies are still good. That’s the part FileGriffon is built to watch.