Digital loss does not always arrive with an empty folder.
Sometimes the filename is still there, the drive still mounts, and the backup directory still looks reassuringly full. The damage appears only when an old photograph opens with a stripe through it, a ZIP file refuses to extract, or a video stops halfway through because some of the stored data no longer matches what was originally written.
That family of problems is often described loosely as bit rot, data corruption, or loss of fixity. The cause may be media failure, transfer error, filesystem damage, software fault, or some other unintended change; not every corrupt file literally represents a storage bit spontaneously flipping. What matters to preservation is that the file still exists while its contents are no longer what they were supposed to be.
A copy is not proof that the copy is good
Modern storage devices contain error detection and correction, so random corruption is not something every file experiences every week. But silent corruption is a documented storage problem rather than a campfire story. A large USENIX study of production storage systems analyzed 1.53 million disk drives over 41 months and found more than 400,000 checksum-mismatch events. Personal collections are much smaller, but the underlying lesson is the same: stored data can change without an obvious deletion event.
The preservation world treats this as a normal engineering problem. The Library of Congress says fixity information should be established as early as possible and then monitored through routine integrity reviews. The National Digital Stewardship Alliance likewise makes file integrity one of the core areas in its Levels of Digital Preservation.
A checksum is the basic tool. Software runs the file through a hashing algorithm and records a value derived from its contents. Months or years later, the checksum can be calculated again. If the value changed unexpectedly, the archive knows the file changed too.
That is important because corruption is often silent. Without a previously recorded checksum, an old file may look suspicious but there is no reliable baseline proving whether it changed.
Checksums detect damage; copies repair it
A checksum cannot reconstruct a damaged photograph. It only tells you that the photograph is no longer identical to the copy you intended to preserve.
Recovery requires another known-good copy: perhaps on a second drive, an offline disk, another family member’s computer, or remote storage. This is why good preservation combines integrity checking with redundancy. Several identical copies stored in genuinely independent places give you something to restore when one copy fails.
There are limits. If three backups were all made after corruption occurred, they may faithfully preserve the same broken file. If no checksum was recorded before the damage, it may be impossible to determine which surviving version is original. And a perfectly intact file can still become unusable if the software or format needed to interpret it disappears.
Personal digital collections therefore need more than storage space. They need occasional verification.
The disturbing thing about bit rot is not that bits decay like old newspaper. It is that digital collections encourage us to believe existence and integrity are the same thing. They are not. A file can sit exactly where you left it for fifteen years and still fail the moment you finally need it.