Backups aren't the only defense against bit rot — and they're expensive if you just want to survive a few flipped bits on a decade-old tarball. par2 (Parchive v2) generates redundancy files alongside your data using Reed–Solomon codes. Feed it 10% overhead and you can rebuild the original after losing up to 10% of the bytes — anywhere in any combination of the covered files, without needing to know in advance which will go bad.

It ships in every distro (apt install par2, brew install par2) and is the same tool Usenet has used for reliable file transfer for two decades.

The basic workflow:

# Create 10% redundancy over a directory of files
par2 create -r10 -n1 archive.par2 *.tar.zst

# Two files result:
#   archive.par2       — small index
#   archive.vol000+NN.par2 — the actual recovery blocks

# Later, verify integrity (fast — just checks hashes)
par2 verify archive.par2

# Something got corrupted? Repair in place.
par2 repair archive.par2

Where it earns its keep: I've watched par2 repair silently rebuild a 40 GB backup archive that had ~200 MB of bad sectors from a dying SSD, in one command, with no user intervention. md5sum would have told me the file was toast. tar would have bailed halfway through. par2 fixed it.

Useful flags you'll actually want:

• -r<N> — redundancy percent. 5% survives casual rot; 10–20% survives serious damage; 100% is a full mirror.
• -n<N> — number of recovery volumes. -n1 keeps it in one file; -n7 splits so you can spread volumes across media.
• -s<bytes> — block size. Smaller blocks = finer-grained repair but bigger index. Default (auto) is usually right.
• -B<dir> — base directory. Necessary when the source files aren't in $PWD.
• -q / -qq — one q hides progress, two silences almost everything (good for cron).

A pattern I use for cold archives on rotating cheap disks:

tar --zstd -cf snapshot-$(date +%F).tar.zst /data
par2 create -q -r15 -n1 snapshot-$(date +%F).tar.zst
# Ship both the .tar.zst and its .par2 companions to two locations.
# If either copy corrupts, either .par2 set can heal it back to original.

Why not just rely on ZFS/Btrfs scrub? Because par2 rides with the file. Move it to a FAT32 stick, upload to S3 Glacier, email it to a colleague, burn it to BD-R — the recovery data travels along. It's format-agnostic and filesystem-agnostic. Cloud storage checksums tell you a file went bad; par2 lets you actually fix it.

Why not sha256 + duplicate copies? Duplicates cost 100% overhead. par2 lets you pick your survivability/cost tradeoff at the byte level, and heals partial damage even when both copies have different corruption — you can feed multiple damaged copies into par2 repair and it will cherry-pick good blocks from each.

Caveat: par2 protects file contents, not filenames, mtimes, or ACLs. Wrap the whole archive in tar first so metadata rides along inside the payload.