430 No Such Article

Most people never see the literal string 430. Newsreaders translate it into a per-segment failure counter, a log line reading article not found, or a job that finishes flagged as missing articles. Because the server answers per article and a binary post is thousands of articles, the useful number is never whether 430s occurred but what share of the file set they cover.

Why a handful of scattered 430s are expected

Every article in a post is stored, propagated, and expired as an independent object. Servers lose individual ones for ordinary reasons: a spool write failed during a peering burst, one article arrived malformed and was refused, an expiry pass caught a straggler a day early. Posters assume this will happen, which is why .par2 recovery blocks are published alongside a release. A download that reports a few dozen missing articles out of several thousand and then repairs cleanly has behaved exactly as designed. A client configured to abort the queue on first failure hides that normal behavior; the Article retry and failover settings should be allowed to finish before anything is called broken.

The reasons an article is absent

• Retention. The post is older than the binary retention that server keeps. This is by far the most common cause and it is a property of the server, not the release.
• Removal. The article was deleted from that operator's spool. Other operators who received no notice may still carry it, which is why one server returns data and another returns 430 for the same article.
• Propagation. The article never arrived on that backbone at all, usually because it was posted to a peer whose feed to that backbone was broken or filtered at the time.
• Incomplete at source. The poster's upload failed partway through, so the articles were never created anywhere. No provider can supply them.

Reading the pattern rather than the count

Scattered failures spread thinly across many files point at ordinary spool loss and are repairable. Failures concentrated in one contiguous run of segments usually mean a single article range was removed or a single peering gap. Failures on every segment of every file mean the release is simply not present on that server, and no amount of retrying will change that. A quick way to separate the last case from the others is to check the age of the post against the advertised retention: an .nzb older than the server's retention window will fail totally and predictably.

Who is at fault, and what actually restores the file

Fault is almost never local. The client asked correctly and the server answered honestly. The indexer shares some of it when the entry it lists was never verified against a live spool, which is how a long-dead release stays searchable for years. For partial loss the remedy is parity: let the repair stage consume the recovery blocks. For total loss on one server, the only technical remedy is a source on a different backbone, since a second account on the same backbone holds the same spool and returns the same code. Articles an operator has removed are a fact of how the service is operated and are not recoverable by retrying elsewhere on the same network.