You download a 40 GB release, it hits 97% and stops. The status sits on “repairing” for ten minutes and then spits out a file that will not extract. If you have used Usenet for more than a week, you have met PAR2 — even if you have never consciously thought about it. This guide is the explainer most Usenet sites never write: what PAR2 recovery files actually are, how a repair works under the hood, why a file fails despite your provider’s giant retention number, and the settings in SABnzbd and NZBGet that decide whether a download lands clean or dies at the finish line.

If you are new to the whole system, read What is Usenet and how does it work? first — this page assumes you know what an article and an NZB are. If you want the theory behind why repairs are needed at all, that is the retention guide. This page is the practical one: how to fix the download.

What PAR2 Actually Is

PAR2 stands for Parity Archive, volume 2. It is an error-correction scheme, not a compression format and not a container. When someone posts a binary to Usenet, the tools that build the release also generate a set of parity (.par2) files and place them alongside the main archives in the same post. Your provider stores those parity files exactly like any other article, and your downloader fetches them as part of the NZB.

The idea is the same one behind a RAID array, or a checksum puzzle in a crossword. Instead of storing the file once, the poster stores the file plus a small percentage of extra mathematical “checksum” data. That extra data is engineered so that any missing piece of the original can be reconstructed from the pieces that did survive. Lose a random 4% of a release, and a 10% parity set rebuilds you a byte-perfect original — no re-download of the missing chunks required.

Two numbers matter, and they are related but distinct:

  • Parity volume — the percentage of extra data the release ships with. Almost always 5–10%. This is your hard repair ceiling.
  • Recovery blocks — the parity data counted as discrete blocks. Each block you have can fix one equivalent block of missing data, up to the total parity.

That first number is the one that decides whether you get your file. Remember it: you can only repair as much as the poster shipped.

PAR2 is a set, not a single file

Almost every release comes with a PAR2 set — typically one small index file (like release.par2 or release.vol00+01.par2) and a stack of larger volume files (release.vol01+04.par2, release.vol05+08.par2, and so on). The index tells your downloader which files belong to the set and what to expect; the volume files carry the actual recovery data.

You can see this in the NZB before you ever download. Pull any NZB into a text editor and you will find .par2 filenames listed right after the main archives. That presence is what tells SABnzbd and NZBGet that a release is repair-capable at all. If the indexer’s NZB omits the parity files, you have no repair headroom — a point I come to in the indexers guide.

What it is not

Three quick clarifications that save arguments:

  • PAR2 is not RAR. RAR is compression and volume splitting; PAR2 is error correction. A release has both, and they do different jobs: PAR2 puts missing data back, RAR packs it small. A RAR volume that is corrupt is a job for PAR2; PAR2 itself never compresses anything.
  • PAR2 is not a download accelerator. It is not downloaded “for speed.” It is downloaded so a damaged post can be salvaged. Downloading more parity than you need is pure overhead — which is why the percentage is small.
  • PAR2 is not new. The format dates from 2003 (an improvement on the original PAR), and it has been the standard for binary Usenet ever since. The tools have changed; the maths has not.

How Repair Actually Works (the bit most explainers skip)

Here is what happens between “download finished” and “extracting”:

  1. Download. SABnzbd or NZBGet pulls every article listed in the NZB — the archives, plus the smallest PAR2 index file, then only the extra parity blocks it actually needs. Neither client grabs the whole parity set up front.
  2. Verify. The downloader reads the PAR2 index, hashes what it received, and compares it against the checksums. It now knows exactly which articles are missing or corrupt, and how many.
  3. Decide. If nothing is missing, verification passes and repair is skipped entirely — no CPU cost, straight to extraction. If data is missing, the downloader checks whether the parity set contains at least as many recovery blocks as there are damaged blocks.
  4. Repair. If it does, the downloader runs a Reed–Solomon decode — the same family of maths used in CD error correction — reconstructing the missing blocks from the parity. It writes a complete, correct set of archives out.
  5. Extract & rename. The now-complete archives are unpacked and renamed into your media folder.

Two things about step 4 are worth internalising:

  • Repair is all-or-nothing at the block level. The downloader cannot “half repair.” If you are one recovery block short, the repair fails and you get the same broken file you started with. There is no partial credit.
  • Repair is CPU-bound and I/O-heavy. The Reed–Solomon decode runs across the entire file, not just the missing part, and it hammers both CPU and disk. On a fast line and a beefy box you never notice it. On a low-RAM NAS or a Raspberry Pi, this is exactly where a download that was cruising at full speed stalls — the network is done, the CPU is not. Which is why the SABnzbd vs NZBGet choice matters more than people think once repairs get big.

Why a File Fails Despite High Retention

This is the confusion that trips up almost everyone, and it is worth slowing down for. You bought a provider with 6,000 days of retention — sixteen years — and a file from two years ago still failed its repair. How?

Because retention and completion are two different things, and repair sits on top of both.

  • Retention says how long articles are kept. It is a promise about the calendar.
  • Completion says how many of the articles you ask for the provider can actually serve. It is a promise about the reality inside that window.
  • PAR2 is the emergency budget that papers over the gap between the two — but only up to the parity the release shipped with.

A provider can truthfully advertise 6,000 days and still hand you a 96%-complete post, because chunks of it were never propagated to their spool, or got taken down after a rights complaint. Here is the sentence to remember, because it is the whole article in one line: PAR2 can only repair the difference between what you got and 100% — and only up to its parity cap (usually 5–10%). If your completion gap is bigger than the release’s parity, no repair can save it, no matter how deep the retention.

That is exactly why the retention explainer argues completion beats a big retention number, and why a multi-backbone provider is really a second repair budget: when one spool’s copy is short a few articles, another backbone’s copy is complete, and the download never needs to repair at all.

The five ways a download actually breaks

If you know the failure mode, you know the fix. In rough order of frequency:

  • Missing articles from the spool. The single biggest cause. Articles aged out, were never propagated, or were removed. Shows up as “not enough repair blocks” when the gap exceeds parity.
  • Takedowns and DMCA removals. A chunk of a popular release gets pulled from one backbone while the rest survives. Another reason the same post can complete on one provider and fail on another.
  • Propagation gaps. With tens of petabytes a day crossing the network, some articles simply do not land on every spool. Random, transient, and exactly what a second backbone covers.
  • A bad or incomplete NZB. If the indexer’s NZB mis-points the parity files or carries dead article references, your repair tool is working from a broken map. Quality here is not cosmetic — the indexer guide’s PAR2 section is worth reading for this alone.
  • Local failures. Disk errors on the download side, not the Usenet side. If your download lands on a failing drive, the article arrives corrupt and PAR2 sees damage that was never Usenet’s fault. Check your disk before you blame your provider.

Fixing It: SABnzbd

SABnzbd does PAR2 for you. You do not normally invoke a repair command; you make sure it can. The settings that matter:

  • Post-processing level. This is a per-job option with a per-category default, set under Config → Categories → Default (choose Repair, or Repair + Unpack + Delete). It is not on the Switches page. This is what tells SABnzbd to verify and repair rather than accept whatever arrived. If you have a download that refused to repair, check this first — it is the usual culprit.
  • Maximum retries (under Server). SABnzbd retries a failed article a set number of times per server. Raising this above the default helps when a spool hiccups on a single article — a surprising share of “missing” articles are transient and come back on a second pass at zero extra cost. To pull missing articles from a different spool instead, give SABnzbd a second server at a higher priority number and tick Optional (the block-accounts guide covers this). What SABnzbd lacks is NZBGet’s retry-after-failure action — not the ability to use a second server.
  • Repair threads. SABnzbd has no dedicated repair-threads field; you set it under Config → Switches → Extra Par2 parameters, which is passed straight to the par2 command line. Use -t — -t1 forces a single thread, and omitting it uses every core. On a low-power box, -t2 is a sensible cap; more threads than cores just makes the machine thrash.
  • Propagation delay. If you grab releases the instant they post and see frequent “not enough repair blocks,” add a propagation delay (10–30 minutes). You are fetching before the post has finished spreading across backbones; waiting lets the missing articles arrive.

When a download is stuck repairing or has failed, the sequence is: pause the queue, make sure your backup server is enabled, and give the release a propagation delay before the next attempt. If it still fails on the same backbone, the post is genuinely short its parity there — that is a job for a second source, not a setting.

Fixing It: NZBGet

NZBGet is the lighter, lower-RAM alternative, with its own multithreaded PAR2 verifier and repair engine built into its C++ core — the same job SABnzbd hands to the external par2cmdline, but far gentler on constrained hardware. See the full comparison for the resource trade-offs; here are the repair-specific bits:

  • ParCheck / ParRepair. Under Settings → CHECK AND REPAIR, make sure ParCheck is set to Auto or Force and ParRepair is on (both are defaults). ParCheck verifies; ParRepair rebuilds.
  • ParThreads. NZBGet exposes a thread count for repair; leave it low (1–2) unless repairs are the bottleneck.
  • ParBuffer and disk. Repair streams through a buffer — if you see heavy disk thrash, give it more room or move the download to faster storage.
  • Secondary server + Retry failed articles. Give NZBGet a second server (a block account) and it can re-request articles your primary could not supply; ArticleRetries sets how many times it retries an article before giving up. That is the mechanism that pairs with a block account — its separate dupe handling is only duplicate detection, not repair.

The headline advantage is the same one that makes NZBGet the pick for NAS boxes: its verifier and repair are built into a C++ core and parallelise well, so a repair that would stall a low-spec SABnzbd box just churns through. On a modern desktop, the difference vanishes.

Can You Repair PAR2 Manually?

Yes — and it is occasionally useful, but for a very narrow set of cases.

  • QuickPar (Windows) is the classic GUI. Open the .par2 index file, it scans the accompanying files, shows you what is missing, and repairs it with one click.
  • MultiPar is the modern Windows successor with more options and better multi-core use.
  • par2cmdline does it on the command line on Linux/macOS — the very engine SABnzbd shells out to for verification and repair (NZBGet instead uses its own built-in implementation).

The catch: manual repair only works if you already have the .par2 files on disk. If you never downloaded the parity set, there is nothing to repair with, and no GUI can invent it. This is why “just repair it manually with QuickPar” is useless advice for a download that failed because the parity was never fetched — and why it is almost never worth doing in an automated setup. Let the downloader handle it and spend your time fixing the cause (completion, indexer quality, a second backbone) instead of the symptom.

“Not Enough Repair Blocks” — the Only Fix That Works

Sooner or later you will see the error that ends all hope: “repair failed: not enough repair blocks.” It is worth being blunt about what it means, because there is a lot of voodoo online about it.

It means the download is missing more articles than the parity set can cover. You are past the release’s recoverable limit on your provider’s copy of that post. No amount of requeuing, thread-tweaking, or “repair harder” changes that arithmetic — the missing data does not exist on the spool you are pulling from.

The genuine fixes, in order:

  1. Add a second source on a different backbone. This is the real one. A block account from another backbone gives your downloader somewhere else to pull the missing articles. SABnzbd and NZBGet support a “fill” or “backup” server exactly for this: primary provider first, backup picks up what it cannot complete. This is the single most effective PAR2 fix in existence — see how it is set up in the block accounts guide.
  2. Pull a different release. If the same content was posted again (a re-post, a different group), its parity set is fresh and the download may repair cleanly.
  3. Find a better NZB. If every copy of a release fails, the indexer’s NZB may be the problem. The indexer quality angle is real.

What is not a fix: buying more retention. The bytes are gone from that spool; a deeper one would not have helped. And this is the practical reason a multi-backbone account like NewsgroupDirect’s Grand Slam (NewsgroupDirect + Supernews + Usenet.Farm + ViperNews behind one login) keeps earning its place: coverage across backbones is a repair budget that does not run out at 10%.

The UK Angle: Repair, Speed and Fair Use

Two UK-specific notes, because they shape how repair feels in practice.

  • Repairs want CPU, and cheap UK setups skimp on it. A lot of UK Usenet users run SABnzbd on a NAS or a small home server to keep the download box quiet and low-power. That is a great choice until repairs get big — then a CPU that only had to shuffle bits suddenly has to run a Reed–Solomon decode, and the finish line is where it stalls. If you are on modest hardware and see frequent stalls at 99%, your repair phase is the bottleneck, not your line speed. NZBGet or a faster box is the honest fix.
  • FUP interacts with repeated downloads. If a download fails and you re-pull it, you have paid for that data twice. On a block account that costs you GB; on a UK broadband fair-usage policy it nudges you toward a cap. The lesson is the same either way: fix the cause of failed downloads (completion, a second backbone) rather than re-rolling the dice, and you spend less on wasted transfers. The cheapest providers guide costs this out properly.

The Honest Recommendation

PAR2 repair is not a feature you shop for — it is a property of almost every release you download, and a good provider simply makes it rare. The purchase that actually reduces your repair failures is a second backbone as a fill server, which is cheap and permanent:

  • Already on an unlimited provider? Add a NewsgroupDirect block account and point it at the fill/backup slot. When a release comes up short on your main spool, the block silently covers the gap and the download completes — often with PAR2 never needing to run at all.

👉 Grab a NewsgroupDirect block account here — a small block is a cheap test; a bigger one becomes the permanent second backbone that makes “not enough repair blocks” disappear.

For the theory underneath all of this — why a 6,000-day spool can still give you a 96% file — read Usenet retention explained. For the downloader whose repair engine you are actually relying on, see SABnzbd vs NZBGet.

Affiliate disclosure: this page contains affiliate links. If you sign up through them we may earn a commission — at no extra cost to you. It never changes what we recommend; a second backbone on a block is covered here because it genuinely fixes the problem, not because anyone paid for the placement.

FAQ

What are PAR2 files on Usenet? PAR2 (Parity Archive, volume 2) files hold redundant error-correction data posted alongside a release, usually 5–10% of its size. Your downloader uses that parity to mathematically reconstruct any articles that are missing or corrupt, so a slightly incomplete download can still be rebuilt into a perfect file.

How do I repair an incomplete Usenet download? You usually don’t — your downloader does it automatically. SABnzbd verifies the completed articles against the PAR2 set and runs a repair when it detects missing blocks. If a download is stuck, requeue the NZB and make sure your backup server is enabled so it can re-fetch the missing articles before repairing.

Why does PAR2 repair fail? Almost always because the download is missing more articles than the release’s parity can cover. PAR2 can only reconstruct up to the redundancy that shipped with the post — typically 5–10%. Lose more than that and no repair can save it, however many times you retry.

Can I repair PAR2 files manually? Yes, if you have the .par2 set on disk. QuickPar and MultiPar on Windows can repair, and par2cmdline does it on the command line. But there’s almost no point — SABnzbd runs the same repair engine automatically, and NZBGet has its own built into its core, so manual PAR2 is only worth it for one-off files pulled outside a downloader.

What does “repair failed — not enough repair blocks” mean? It means the download is missing more data than the parity set can cover. The release is past its recoverable limit for your provider’s copy of the post. The fix is not to repair harder — it’s to pull the missing articles from another source, usually a block account on a different backbone.

Does PAR2 repair need more CPU or RAM? Yes. Repair is a Reed–Solomon decode across the whole file — CPU-bound and I/O-heavy. On a low-RAM NAS or a Raspberry Pi, repair is exactly where a fast download stalls at the finish line. If that’s your setup, NZBGet handles the decode more lightly than SABnzbd.

Where to Go Next