← Back to blog

July 13, 2026

Bit Rot Doesn't Send a Warning

A drive dying is loud. SMART warnings, clicking noises, a boot failure — you notice, and you act. That’s not how most people actually lose data.

The more common failure looks like this: a composite of stories we’ve heard from photographers, archivists, and home-server users over the years. A RAW file gets copied to a backup drive. The copy looks fine — same file size, opens without an error at the time. Months later, someone goes looking for that file and finds a few kilobytes of it replaced with garbage. Nothing alerted them. The drive never reported an error. The file just quietly rotted, and nobody was watching closely enough to catch it at the moment it happened.

Why this keeps happening

A few reasons bit rot slips past people who are otherwise careful about backups:

What we’re building

FileGriffon is a background service that hashes every file in a vault (a folder or drive you point it at) and re-checks those hashes on a schedule. If a file’s contents silently change outside of a normal edit — corruption, a bad copy, a failing sector — it shows up on the dashboard as soon as the next scan runs, not whenever you happen to open that file again. Where parity protection is enabled, it can also repair certain damage automatically.

The goal isn’t to replace backups. It’s to catch the failure mode that backups alone don’t: the file that’s already broken by the time it gets backed up, or the copy that quietly diverges from the original.

FileGriffon isn’t released yet. This blog is where we’ll post development progress, and writing like this on data integrity and backup practice in general. If you’ve got a bit-rot story of your own, we’d like to hear it eventually — for now, there’s nowhere to send it yet, but that’s coming too.

bit-rotdata-integritywhy-filegriffon