Bit rot is the failure mode nobody plans for: a file that was fine last year won’t open today, no error, no warning, no dramatic failure to point to. One bit somewhere flipped from a 0 to a 1, and now something chokes on it. Everyone plans for the drive dying. Almost nobody plans for the drive quietly lying to them instead. There’s a tool built specifically for this, decades old, still actively maintained, and most people have never heard of it: PAR2.

What PAR2 actually does

PAR2 (Parchive) came out of Usenet binary posting culture, back when a corrupted download over a flaky connection was a routine annoyance. It generates a separate recovery file made of parity blocks, mathematically derived redundancy, that can patch damage in the original file after the fact.

That’s the part people miss: it’s not a second copy. A second copy just gives you two things that can each independently rot, which is a strange way to feel safer. PAR2 instead reconstructs the missing pieces from the parity data, the same underlying idea RAID 5 and QR codes use, except nobody’s ever put PAR2 on a slick landing page with a mascot, so it just quietly works in the background of Usenet clients while getting none of the credit. You tell it how much redundancy to build in, as a percentage of the original file’s size. More redundancy means a bigger recovery file and a higher tolerance for damage before repair becomes mathematically impossible.

It doesn’t matter where the damage lands or what kind of file it is. A flipped bit in a photo, a video, a zip, a tar, a spreadsheet: PAR2 doesn’t parse the file’s internal structure at all, it just treats it as a sequence of blocks and can rebuild any block it’s lost, up to the redundancy budget you paid for. And it’s the same tool, same file format, whether you’re on Windows or Linux.

Meet TAR, ZIP’s older, less compressed cousin

Most people who’ve never touched Linux still know ZIP. Fewer know TAR, so it’s worth a quick introduction before using it: TAR (Tape Archive) does the same basic job as ZIP, bundling a folder full of files into one, but it’s built differently, and that difference is exactly why it’s the better pick for something you’re protecting with PAR2.

ZIP keeps a table of contents at the end of the file, a central directory that lists every file inside and exactly where to find it. Every extraction starts there. It’s efficient, and it’s why you can open a huge ZIP and see its contents instantly instead of reading the whole thing. The catch: that table of contents is a single point of failure. Damage a few bytes in it and the archive tool has no way to find any of your files, even though every byte of actual data is still sitting right there on disk, untouched. Somebody traded speed for survivability decades ago, and you’re the one who inherits that trade the day your archive won’t open.

TAR doesn’t have a central directory at all. It’s a much older, simpler design: header, file data, header, file data, repeated for every file, with nothing at the end tying it together. Each file is self-contained. That means damage to one file’s header only costs you that one file. Everything before it in the archive is unaffected, and most tar implementations will scan forward, find the next valid header, and keep extracting everything after it too.

One practical wrinkle on Windows: ZIP gets special treatment from File Explorer. Double-click a .zip and it opens like a regular folder, no extra software required. TAR doesn’t get that, tar.exe being built in only covers the command line, so double-clicking a .tar with nothing else installed just gets you Windows asking what app to open it with. Grab 7-Zip to fix that: free, open source, handles tar the same way Explorer handles zip, browse inside without extracting anything. Genuinely one of the better pieces of free software still around, worth having regardless of whether you ever touch PAR2. Or skip the GUI entirely and list what’s inside from the command line: tar -tvf florida-trip.tar.

Skip whole-archive compression, though. tar czf photos.tar.gz photos/ pipes the whole thing through gzip as one continuous stream, and a bit flip early in that stream can desync the decompressor for everything downstream of it, right back to the single-point-of-failure problem you were trying to avoid. Leave the tar uncompressed. Photos, videos, and most things worth archiving long-term are already compressed anyway, so there’s nothing to gain from tar czf and a real downside to it. Give me a boring, uncompressed archive that survives a bad byte over a clever, compressed one that doesn’t, every time.

Backing up a folder of photos, step by step

Say you got back from a trip to Florida last year with a folder of 250 JPGs, roughly 8MB each, around 2GB total. You want that folder on an external drive for years, and you want it to still open the day you actually go looking for it.

1. Bundle the photos into one archive

Windows ships a real tar.exe in C:\Windows\System32 on Windows 10 (since build 17063) and Windows 11, based on the same libarchive code as the Linux and macOS versions, signed by Microsoft. No install needed, works from Command Prompt or PowerShell:

> tar -cf florida-trip.tar florida-trip\

Linux:

$ tar -cf florida-trip.tar florida-trip/

2. Checksum the archive

This gives you a fast way to notice damage later without needing PAR2 at all, just to know something changed.

Windows, built into PowerShell:

> Get-FileHash florida-trip.tar -Algorithm SHA256

Linux:

$ sha256sum florida-trip.tar > florida-trip.sha256

3. Generate the PAR2 recovery data

Windows: PAR2 doesn’t ship with Windows, but the community client is MultiPar, a GUI front end for the same PAR2 engine. The interface looks like it wandered out of 2006 and never left (it’s inherited from an even older tool called QuickPar), but it works, and free-and-slightly-ugly beats nothing every time. Get it from that GitHub releases page specifically; there’s a lookalike scam site at multipar.eu that ranks near the top of search results and is not the real thing, because of course there is. Drag florida-trip.tar into MultiPar, set the redundancy to 15%, and click “Make.”

Linux:

$ par2 create -r15 florida-trip.tar.par2 florida-trip.tar

-r15 means 15% redundancy: for a 2GB archive, that’s roughly 300MB of recovery data. That’s the real cost of this whole approach, disk space, and it’s a fraction of what a full second copy of the archive would cost.

What your folder looks like afterward. Either tool leaves you with a batch of new files sitting next to the original archive:

florida-trip.tar
florida-trip.sha256
florida-trip.tar.par2
florida-trip.tar.vol000+001.par2
florida-trip.tar.vol001+002.par2
florida-trip.tar.vol003+004.par2
florida-trip.tar.vol007+008.par2
florida-trip.tar.vol015+016.par2
florida-trip.tar.vol031+032.par2
...

The .par2 file with no volume number is the index; it describes the archive and how many recovery blocks exist. The .volNNN+MM.par2 files are the actual recovery data, split into chunks that double in size each time so the tool can pick exactly how many it needs for a given repair instead of reading everything. You don’t do anything with these individually. Keep the whole batch together, in the same folder as florida-trip.tar, and leave the original filename alone. PAR2 can often recognize a renamed file by content and fix the name back during a repair, but treating the filename as fixed is the simple habit that avoids relying on that.

4. Verify and repair

Windows: MultiPar’s “Verify” button checks the archive against its recovery data. If it finds damage, “Repair” fixes it in place.

Linux:

$ par2 verify florida-trip.tar.par2
$ par2 repair florida-trip.tar.par2

If nothing is damaged, verify just says so and exits. If something is, you’ll see exactly how many blocks were affected and whether repair is possible with the recovery data on hand, then the repair itself rewrites the archive back to its original state. This is worth doing on a schedule, not just when you happen to remember, which is a nice way of saying you probably won’t unless you calendar it. An archive nobody checks isn’t a backup, it’s a rumor you’re telling yourself.

The redundancy budget has a hard limit

-r15 doesn’t mean “this archive can never be damaged.” It means roughly 15% of the archive can be reconstructed from the recovery data, spread anywhere across the file. Push past that and the math genuinely runs out. There’s no partial credit, no plucky last-second save, the universe just says no. When that happens, par2 verify doesn’t fail silently or lie to you: it says plainly that repair isn’t possible and tells you how many additional recovery blocks you’d have needed.

That’s a fundamentally different failure mode than the corrupted ZIP index from earlier. You’re told exactly what happened and exactly what would have fixed it, instead of losing the whole archive with no explanation. The fix for next time is generating recovery data with more headroom, -r20 or higher, not losing the archive. For something like the Florida photos, sitting untouched on a shelf for years with nobody checking on it, the extra disk space for a bigger redundancy budget is worth it.

What this doesn’t fix

None of this saves you from a dead drive, a fire, or “I forgot where I put it.” PAR2 and TAR’s own header-recovery behavior are for one specific, sneaky failure: the media looks fine, the file is still there, and a handful of bits have quietly gone bad without telling you. That’s a real and common failure for anything sitting untouched for years, which is exactly what happens to a drive full of vacation photos nobody looks at again until the next trip reminds them. Build the recovery data before you need it, and the old 3-2-1 rule (three copies, two media, one offsite) still applies on top of it.

PAR2 fixes bit rot. It doesn’t replace a real backup strategy.