The basics
Three terms explain almost everything on this site: the NZB file, the backbone and the difference between retention and availability.
What is an NZB file?
An NZB file is a small XML file that lists every Usenet article that belongs to a post – like a table of contents. It contains no content itself.
Binary posts on Usenet are split into many small articles (also called segments) – often several thousand for a single post. The NZB lists the unique message-ID of each article, grouped by file, along with the newsgroups, the poster and the posting date.
Download clients such as SABnzbd or NZBGet read the NZB, fetch every listed article from your Usenet provider and put the files back together. If some articles are missing on your provider, the download is incomplete – which is exactly what NZB Mentor checks in advance.
Backbones and providers
A Usenet backbone is the server infrastructure that actually stores Usenet articles. A provider is the company you buy access from. Many providers rent access to the same backbone and therefore deliver the same articles.
Only a handful of backbones exist. Each has its own storage, its own retention and its own way of handling takedown notices – which is why the same article can be available on one backbone and missing on another. NZB Mentor currently tests seven: Omicron, Abavia, UsenetExpress, Netnews, Giganews, Uzo Reto and Its Hosted.
Two providers with different names and prices can run on the same backbone; for download completion they are then practically identical. They differ in price, number of connections, server locations, extras and customer service. Some providers also run their own servers or caches, so small differences are possible.
Retention vs. availability
Retention is what a backbone promises: how long it keeps articles. Availability is what we measure: the share of an NZB's articles you can actually download right now.
Retention is stated in days – 6000 days means articles up to about 16 years old are kept. It is an upper limit, not a guarantee. Inside the retention window, articles still go missing:
- Takedowns. Rights holders send removal notices (DMCA in the US, NTD in Europe). Each backbone handles them on its own, at its own speed.
- Incomplete propagation. Articles are copied between backbones after posting; sometimes not every article arrives everywhere.
- Storage changes. Backbones occasionally lose data, for example after hardware failures or storage migrations. Articles that were available last month can then be gone, even when they are well within the retention period. We cannot see the cause from the outside, only that articles are missing.
That is why NZB Mentor measures availability instead of relying on advertised retention.
How a check works, step by step
From the moment you drop your file, the result usually takes about a minute. This is what happens in between.
You choose an NZB file
Only .nzb files up to 10 MB. Your browser reads the file; only the article IDs, the posting date and the number of PAR2 articles are sent to us. What exactly is shared?
Your browser reads the NZB
Your browser extracts the article IDs (message-IDs) and the posting date, and counts the PAR2 recovery data. You see the number of files, articles and the size immediately.
We connect to every backbone
For each of the seven backbones we open several parallel connections through one representative provider – the “tested via” provider (see the table below).
We request a sample of articles
For each backbone we send the NNTP
BODYcommand for a random sample of 100 articles, spread evenly across your NZB, on all backbones in parallel. If the result is clear-cut (almost everything or almost nothing is there), 100 articles are enough. If it is not, we add more articles – up to 600 – until the margin of error is about ±4 percentage points. NZBs with 100 articles or fewer are checked completely.An article counts as available when the backbone returns its complete body. It counts as missing when the server answers “no such article” (code 430), reports a takedown (code 451), or returns an empty or cut-off article. If a request fails because of a connection problem, we try it once more; if that also fails, the article is left out of the calculation instead of counted as missing. If more than half of the requests to a backbone fail, that backbone gets no result for this check.
We discard the data
While an article is received, we only check that it is complete (not empty and not cut off). Nothing is decoded, saved or put back together into files. We only count.
We calculate your result
Per backbone: the share of requested articles that was available (calculated from the sample for the whole NZB), the estimated number of missing articles, and the status Complete, Repairable or Incomplete (see chapter 3).
We update the statistics
The anonymous counts flow into the retention comparison and backbone performance. The file itself never reaches our server.
Why BODY and not STAT?
The lighter STAT command only asks whether a server knows an article ID. Some providers answer STAT positively even when the article itself is gone, which makes a backbone look better than it is – we saw this in our first version. BODY actually transfers the article – exactly what your download client does – and lets us check that it arrives complete, so our numbers match real downloads.
Why one provider per backbone?
Providers on the same backbone draw from the same article storage. Testing several providers per backbone would multiply the cost without changing the result much. Exceptions exist – some providers add their own caches or storage – and we mention them where we know of them.
| Backbone | Tested via | Server region |
|---|---|---|
| Omicron | Eweka | EU · NL |
| Abavia | XS News | EU · NL |
| UsenetExpress | NewsDemon | EU · NL |
| Netnews | Frugal Usenet | EU · NL |
| Giganews | Giganews | EU · NL |
| Uzo Reto | Vipernews | EU · NL |
| Its Hosted | Usenet.Farm | EU · NL |
The region shows where the server we test through is located. It mostly affects speed, not which articles exist; a few backbones run separate clusters per region whose content can differ slightly.
Reading your result
Availability is the share of your NZB's articles that a backbone delivered. 100 % means no article was missing in our sample. The status tells you whether a download from that backbone alone will work:
| ✓ Complete | No missing articles were found in the sample. Because we check a sample, a small share (up to roughly 3 %) can still be missing. Download as usual. |
|---|---|
| ↻ Repairable | Some articles are missing, but less than the PAR2 recovery data in the NZB. Your download client can most likely rebuild the missing parts. |
| ✕ Incomplete | More is missing than PAR2 can repair. The download fails unless you add a second server on another backbone. |
“Repairable” is an estimate: PAR2 works on blocks, so if the missing articles are unevenly spread or hit the PAR2 files themselves, a repair can still fail. All results are estimates based on a sample of articles, so they can differ slightly from what a full download would show.
What is PAR2?
PAR2 files contain recovery data that can rebuild missing or damaged parts of a download. Uploaders often add around 5–15 % recovery data. Each recovery block can replace any one missing data block of the same size (Reed–Solomon codes). If a download misses 3 % of its data and the post has 10 % recovery data, the repair usually succeeds. SABnzbd and NZBGet download PAR2 files only when needed and repair automatically.
If your provider shows “Incomplete”: block accounts
A block account is a prepaid data package (e.g. 500 GB) that does not expire monthly. It is used as a backup server: your download client only uses it for articles your main provider is missing.
Choose a block account on a different backbone than your main provider – otherwise it has the same gaps. In SABnzbd or NZBGet, give your main server the highest priority and the block account a lower one, so it only fills gaps and the data package lasts a long time. It is worth it if NZB Mentor often shows your provider's backbone as “Incomplete” while another one is “Complete”.
How the retention comparison is calculated
The retention comparison groups all checked NZBs by post age and shows, per group and backbone, the share of requested articles that were delivered.
Where the data comes from
The retention comparison is based on two sources: NZBs that our scanner collects automatically from Usenet indexers, spread over many post ages, and NZBs that visitors check on this site. The data therefore reflects what these indexers list and what visitors choose to check – it is not a random sample of everything on Usenet.
Post age
Post age = date of the check minus the posting date in the NZB (the date attribute of the files; we use the oldest). NZBs without a valid date are left out of all public figures, including backbone performance.
Age groups
NZBs are grouped in steps of 6 months (182 days), 1 year or 2 years. The default is 1 year: fine enough to see the differences, coarse enough to stay readable.
Weighting: per article
Each value is all delivered articles in a group ÷ all requested articles in that group. Large NZBs therefore count more than small ones. This answers “how much of the data can I get?”. Averaging per NZB instead would answer “how many posts work?” – both are valid, we chose the first because it matches download volume. When you view 1 or 2 year groups, the page combines the underlying 6-month values, weighted by the number of NZBs in each.
Repeat checks
If the same NZB is checked several times, only the first check counts. Otherwise popular NZBs would dominate the data. We recognise repeats by a one-way hash of the article IDs in the NZB, so the same post from two different indexers is counted once.
NZBs that no backbone has complete
Some NZBs are incomplete on every backbone we test. They always count in the retention comparison.
These NZBs are usually broken, fake, or posts that were removed everywhere. They lower every backbone by roughly the same amount. Leaving them out would filter away exactly the posts that are gone and make backbones look better than they are, so they always count.
Sample size
Every point in the chart shows, on hover, how many NZBs it is based on; the total number of tested NZBs is shown above the chart. Values based on few NZBs can change a lot with every new check. This mainly affects posts older than about 15 years, because few people check them.
How backbone performance is calculated
The backbone performance page shows what each backbone delivered in a chosen period – across all post ages. The ranking, the trend and the scan history follow the selected period; “Oldest complete NZB” and the editorial summary further down are always all-time.
| Availability | All articles delivered by a backbone in the period ÷ all articles requested from it. Large NZBs count more. |
|---|---|
| Complete NZBs | Share of checked NZBs for which no missing article was found on that backbone. Repairable NZBs do not count as complete. |
| Complete on ≥ 1 | Column in the scan history: share of the day's checked NZBs that at least one of the seven backbones had complete – “is it still on Usenet somewhere?”. |
| Trend | Small line next to each backbone in the ranking: availability per day, for at most the last 20 days of the selected period. |
| Oldest complete NZB | Under “Details” per backbone: the age in days of the oldest NZB that this backbone delivered completely, every article included. Only NZBs we checked in full count, and NZBs with fewer than 10 articles are ignored. A measured lower bound, not a promise – and always all-time. |
| Scan history by day | One row per day with the number of checks and the availability per backbone; open a day to see its individual checks – anonymous, without file names. |
Why the numbers change so much between periods
Every check uses a different NZB. On a single day these can be mostly new posts (bad for some backbones) or mostly old posts (bad for others). On a single day, for example, a backbone that leads over 30 days can rank far lower. Longer periods even this out; below 500 checks the page shows a warning. For a fair comparison by post age, use the retention comparison.
What we store and the public comparison
Your NZB file is never uploaded: your browser reads it and sends us only the article IDs, the post date and the number of PAR2 articles. The article IDs are removed from our server’s memory as soon as the check is done. We keep anonymous counts – nothing that identifies the content.
| Kept (anonymous) | Never kept |
|---|---|
| Post age (in days) | The NZB file itself – it stays in your browser |
| Time of the check and whether it came from a visitor or from our own scanner | File names and subjects |
| Requested and delivered articles per backbone | Poster names and passwords |
| One-way hash of the article IDs (to spot repeat checks) | Any downloaded content |
There is no opt-out for the statistics: every check adds anonymous counts to the backbone performance figures, the scan history and the retention comparison. Because no file names or content are kept, nothing in them can be traced back to you or your file.
IP addresses are used only for rate limiting and abuse prevention and are not stored in our statistics. No tracking cookies, no third-party analytics. Details in our privacy policy.
Limitations
No measurement is perfect. These are the limits we know of:
- Indexer bias: the scanner selects NZBs by searching by year and genre at a few indexers. The data therefore reflects what those indexers list, not all of Usenet.
- Sampling: each check looks at a sample of the articles in an NZB, so every value is an estimate.
- One provider per backbone: providers on the same backbone normally see the same articles, but some add their own filters or caches.
- Snapshot in time: each check shows the state at that moment. An article can be removed an hour later.
- Old posts: few NZBs older than ~15 years are checked, so these values are less certain.
- Not measured: download speed, connection limits, price or customer service.
About & independence
NZB Mentor is an independent project. No provider can pay for inclusion, placement or ranking, and every backbone is tested in exactly the same way.
We pay for our test accounts ourselves and use no affiliate links. If that ever changes, we will say so clearly on every affected page. Any backbone can ask to be added.
Contact
Questions, a wrong result, a backbone you are missing, or press enquiries: write to [email protected]. We read every message and add common questions to the FAQ.
Reporting a problem? Please include the date and time of the check. Don't send the NZB unless we ask for it.
Frequently asked questions
No question matches. Ask us directly.
Do I need an account? Does it cost anything?
No and no. NZB Mentor is free and works without registration.
To keep it fast for everyone, there is a fair-use limit of 40 checks per hour per visitor.
Which files can I upload, and is there a size limit?
.nzb files up to 10 MB. That is plenty – an NZB is only a list, so even NZBs for posts of several hundred gigabytes are small.
The file must be a valid NZB (XML). Other file types such as .torrent, .par2 or .rar are rejected. Compressed NZBs (.nzb.gz) are not supported – unzip them first.
How long does a check take?
Usually 20 to 90 seconds. NZBs with many thousands of articles take longer, and at busy times your check may wait in a short queue.
Can I check several NZBs at once?
Not at the moment – one NZB at a time per visitor. Wait for a check to finish before you start the next one.
Which Usenet provider should I choose?
Choose a provider on a backbone with high availability for the kind of posts you download – recent or old. We give you the measurement; compare price, speed and service yourself.
- Think about the age of the posts you usually download.
- Look up that age with the slider in the retention comparison.
- Pick a provider on one of the strongest backbones for that age.
- Optionally add a block account on a different backbone.
We don't recommend specific brands and earn no commission from providers.
How do I find out which backbone my provider uses?
Check your provider's website or its support – many providers state their backbone openly. The “Tested via” column in the ranking shows which provider we used for each backbone.
Technically inclined users can look at the Path header of a downloaded article, which lists the servers it passed through. Some providers use several backbones or their own servers, so the answer is not always a single name.
Why is an NZB complete on one backbone but incomplete on another?
Mostly because of takedowns: backbones receive removal notices and process them independently – at different speeds and to a different extent.
Other reasons are the retention limit, articles that never reached every backbone, storage problems, and different spam filtering. See retention vs. availability.
Why do new posts sometimes have lower availability than older ones?
New posts are the most frequent target of takedown notices, and backbones handle these notices differently.
A post that survives its first months is less likely to be removed later and tends to stay available as long as retention allows.
What is the difference between DMCA and NTD takedowns?
Both are procedures to remove content after a notice from a rights holder: DMCA is the US Digital Millennium Copyright Act, NTD (“notice and takedown”) the procedure under European – especially Dutch – practice. NZB Mentor takes no position on specific content; we only measure availability.
Why does my download client show a different result?
Usually because of time, provider or settings: we check at one moment through one provider per backbone; your download happens later, possibly with a different provider and your own server setup.
- Articles were removed between our check and your download.
- Your provider runs on a different backbone than you think, or mixes several.
- Your client uses several servers (e.g. a block account), which combines their availability.
- Connection errors or too many connections make articles look missing.
Can a provider pay to be ranked higher or to be added?
No. Rankings come only from measured data. To add a backbone we need a test account, which we pay for ourselves; every backbone is tested the same way. See About & independence.
Can I quote your data?
Yes. Please name “NZB Mentor” and link to the page you quote from, e.g. the retention comparison.
Is using NZB Mentor legal?
NZB Mentor is a diagnostic tool: it checks whether articles can be retrieved from Usenet servers. It does not host, index, link to or distribute any content.
Whether downloading a specific piece of content is legal depends on the content and the laws of your country. Only download content you have the right to access.
My upload doesn't work. What can I do?
Check that the file ends in .nzb, is smaller than 10 MB and is a valid NZB.
Open it in a text editor: it should start with <?xml and contain an <nzb element. Some websites deliver an HTML error page saved as “.nzb” – download the NZB again.
The check shows 0 % on every backbone. Why?
The articles no longer exist on any tested backbone.
Typical causes: the post was removed everywhere, it is older than every backbone's retention, or the NZB is broken or fake (the article IDs never existed).