Support

Thank you for the exceptionally good bug report — you pointed straight at the offending line, which made this quick to confirm. It is a genuine bug and it's now fixed.

Your existing backup is fine. The empty trailing part is not a sign of a corrupt archive. All 4,823,449,600 bytes of your data are present in parts .j01 through .j230, and the archive header correctly declares 231 parts, all of which exist on disk. Nothing was lost. The zero-byte part carries no data, so extraction reads right past it. The only thing the empty part actually breaks is the upload: our S3 library rejects any file of zero length before it ever hits the wire, which is where "Missing input parameters" comes from, and that failure is what marks the whole backup as failed.

What's actually going on. Your diagnosis of the mechanism was correct: the split-write loop rotates to a new part whenever the current one fills up, without first checking whether there is any data left to write. When both run out on the same iteration, you get a part that never receives a byte, and JPA finalisation renames the last part to .jpa — so the surplus empty part becomes your final archive.

One refinement, which matters because it explains why this is so rare. It isn't triggered by the total archive size being an exact multiple of the part size. A write that exactly fills a part is already handled correctly and returns without rotating. The condition is narrower: a single compressed block has to span a part boundary and end exactly on the following one. That is a much less likely coincidence than the total size lining up, which is why this has gone unnoticed for years despite split archives being common. It also means it depends on your data, not just your settings. To put it into perspective, this is about 15 years old, you are the first person to hit it – millions of backups before someone hit it.

Until the fix ships, simply re-running the backup will most likely succeed, since the compressed data shifts as your site changes. If you want to be more deliberate, change the part size — 16 MiB or 25 MiB instead of 20 MiB. Any change perturbs the arithmetic and the coincidence will not recur.

The fix is in the backup engine and will be in the next release. I also fixed the same latent problem in the JPS (encrypted archive) writer, where it was producing a similarly pointless trailing part. Both are covered by regression tests now.

Back when I had first written that code, about 16 years ago, I remember having found that problem. However, at the time, fixing it was breaking upload on part finalization. At that point I decided the issue is both extremely unlikely and self-healing: a new full backup is by definition a few bytes longer because of the failed backup's database record now being part of the backup. When I reworked the upload years later I had fully forgotten about this. As soon as I saw your ticket I knew exactly what it was.

Once again thank you for the report! I am not against using AI when it's a genuinely useful tool, and that was indeed one of those cases. If anyone else is reading, that's how you use AI coding assistants, folks.

And yes, do buy that lottery ticket. The issue you hit had longer odds than most lotteries :)