It depends. I would like to note that no, it is not a flaw in the process and no, ZIP files would not be better -- they would be worse
. In fact, the process for splitting archives is not even mine. It was devised by Phil Katz for PKZIP several decades ago and it's been copied for literally every archive format supporting split archives ever since. In short, it's the standard (and only) way to do it.
Let's start with ZIP files which have a normative format specification
. A split archive with three parts is not
three separate ZIP files. It's a single big file which was chopped down in predetermined lengths. The first part is the one with the .z01 extension and has the header of the file, telling the extraction engine that this is a split archive. The last part is the one with the .zip extension and ends with the Central Directory and end of archive markers. If the Central Directory is busted or missing you cannot extract any file from any part of the ZIP archive. In short: if either the first or the last part of the archive is busted you cannot extract a split ZIP file at all. If you have these two parts and there's a corruption in the file data you may
be able to extract some files, as long as the corruption did not change the length of the data by even a single byte.
That necessitated coming up with an archive format that's slightly less finicky than ZIP and better suited for site backups. The JPA format is basically "ZIP lite". It does away with all the ZIP features we can't or don't need to use, including the Central Directory. It still follows the same archive splitting logic as all other archive formats: you don't have three separate archives, you have a single big file that was chopped down in predetermined lengths. The first part is the one with the .j01 extension and has a header that tells us it's a split JPA file. There's nothing special for the other part files. Unlike ZIP files we don't need the last part to extract a multipart JPA file. If you have at least the first part (.j01) you can start extracting the archive with Kickstart, up to the point where a part file is missing or corrupt.
With JPA files you have the option to tell the archive extraction script, Kickstart, to ignore most errors. It will happily skip over corrupt files as long as the header data before its file is intact. If that's corrupt, ugh, we have very limited options which boil down to using a custom script that tries to "guesstimate" where the next file begins and hope for the best. If you're missing entire parts it's even worse because we now have a big "hole" in the big archive, making heuristics even harder.
Before I can tell you if there's anything we can do I need to know if you have all the archive parts and the nature of the corruption (are some bytes screwed up or are the parts truncated).