Updated Sep 30, 2026
Three copies of an export is the 3-2-1 rule. It does not help if all three copies are silently corrupted in the same way. Bit rot is rare on SSDs and uncommon on hard drives, but it happens. The only protection is to verify your files periodically. This guide shows how, on macOS, Windows and Linux, and how often to actually run it.
Most drive failures are loud: the disk clicks, the SSD disappears, the file refuses to open. Bit rot is the opposite. The drive still mounts. The file still opens. Bytes somewhere inside have flipped silently, and your archive is now subtly wrong.
For most files this does not matter. The OpenDocument file you keep "just in case" tolerates a few flipped bits; you would re-download it.
For an export you took once and may need in five years, it matters. The fitness data you have been saving since 2018, the photo library you are about to back up, the AI conversations you want to keep for the long term. These are the files where silent corruption costs you the only copy.
SHA-256 is a cryptographic hash function. You feed it a file of any size; it produces a 64-character string of hex. The same file always produces the same string. A single flipped byte produces a completely different string. There is no known way to construct two files with the same SHA-256.
For verification purposes, this means: keep the string. If the file you have today produces the same string, it is bit-identical to the file you hashed.
macOS ships with `shasum`. Use the `-a 256` flag to select SHA-256.
PowerShell is the modern path. The older `certutil` also works for one-off hashes.
Linux ships with `sha256sum`. Same shape as macOS.
The whole point of a checksum is to detect corruption. If the manifest sits on the same disk as the files you are hashing, it cannot tell you the disk has rotted. Put it somewhere else: a USB stick, an encrypted cloud drive, a paper printout in a drawer. Two copies is fine. The manifest needs to outlive the disk.
All three OSes can re-hash a manifest and report which files changed. Run it once a year, on the same schedule as your exports.
PowerShell does not have a built-in `-c` equivalent to `sha256sum -c`. The pattern below reads a sha256sum-format manifest, re-hashes each file, and prints any that changed.
Right after you take the export: the platform can produce a bad archive, and verifying catches it before you delete the original. Then once a year, on the same cadence as the export itself. Digital Takeout Day is May 8 and November 8. Run the verify on one of those.
SHA-256 verifies files you already have. It does not protect against ransomware, drive theft, fire, or a domain going dark. For those, you need offsite copies and ideally a backup tool with built-in integrity.
On a modern SSD, a single 1TB file hashes at roughly 500 MB/s to 1 GB/s. A 1TB archive of many small files is dominated by I/O and can take much longer. Expect somewhere between 30 minutes and a few hours for 1TB.
You can hash by directory and still catch corruption. The smaller the granularity, the easier it is to identify the corrupted file when something fails. For archives you care about, hash every file. For casual backups, a per-directory hash is fine.
Compare against another backup. If only one copy is bad, replace it from a clean one. If two copies fail the same way, the original was bad and you need to re-export from the platform.
No. SHA-256 detects silent corruption. It does not detect that an attacker, or a bug, replaced your file with something else. For ransomware, you need an offsite immutable copy.
On macOS, Checksum Mosh and HashCheck are common picks. On Windows, HashCheck is the standard free option. On Linux, the command line is usually faster than any GUI.