Support

No matter if you use Akeeba Backup, Akeeba Kickstart, Akeeba eXtract Wizard, Akeeba UNiTE or (in the case of ZIP files) PKZIP for Windows, WinZIP or any other unarchiver the following remains true: all of the part files MUST be present at the same time so that the archive can be extracted, as a whole. That is to say, you cannot separate the .jpa from .j01 - .jnn and you cannot "extract" an arbitrary .jXX file. They are pieces of a puzzle. One piece doesn't make sense by itself. If I give you one puzzle piece and ask you to identify what it depicts you'll have no idea. Combined with all of the other puzzle pieces it makes a picture that makes sense.

Further information

An Akeeba Backup multipart archive consists of several part files: .jpa and .j01 to .jnn; or .jps and .j01 to .jnn; or .zip and .z01 to .znn. These files are part files, pieces of a whole. All together they form ONE archive (backup set). Each one of them is NOT a standalone backup archive and CAN NOT be extracted on its own.

In the case of JPA archives this means that all of the files it consists of (.jpa, .j01, .j02, ...) MUST be in the same directory. When Akeeba Backup, Akeeba Kickstart, Akeeba eXtract Wizard or Akeeba UNiTE is asked to extract the .jpa file it actually does NOT start extracting the .jpa file. In fact, the .jpa file is the last file in the backup set. It starts extracting the .j01 file which is the first file of the backup set. The data of the last file in the .j01 file are incomplete and roll over to the next file, e.g. the .j02 file. So then it begins reading that .j02 file. And so on and so forth until it reaches the last part file of the backup set which is the .jpa file.

Since all part files form ONE archive and MUST be all present for the archive to be extracted it would be rather silly presenting you all the part files in the file picker. Think about an archive with 1345 parts (it's a real thing). You'd see 1345 files, .jpa, .j01, ..., .j1344 but selecting any of them would require us extracting the same archive. So why give you 1345 identical options when one does the trick? Also, since both .jpa and .jps archives share the same naming pattern for parts (.jXX) it would be problematic figuring out what kind of archive you have there without doing some consuming file operations and complicated error catching.

In fact, our software is definitely not the first to deal like that with multipart archives. I believe that the first software to do that was PKZIP (for DOS!) when they presented their split disk ZIP archive format into a split file ZIP archive format (same binary layout but now using part files instead of physical floppies for the ZIP file parts) more than 20 years ago. Their GUI on Windows only let you pick the .zip file. This convention has been picked up by all major and minor unarchivers such as WinZIP, WinRAR, 7-Zip and so on and so forth. Our JPA format was conceived 10 years ago as a simpler ZIP format without the baggage of backwards compatibility. Naturally, we followed the same conventions as the ZIP format :)

Please note that I have written the JPA specification myself. Moreover, I have implemented the archive extraction algorithm myself in PHP (Kickstart, Akeeba Backup, UNiTE), Pascal (eXtract Wizard 3.x) and C# (eXtract Wizard 4.0, not yet released). I know how it works and I explained that to you. Insisting that something else, which I clearly explained is not possible due to the nature of the format, is not productive. You are insisting on an impossibility and you're trying to convince me. It's like trying to convince an astronomer that the Earth is flat. Can we please agree that I know how that works and try to help you? :)

Based on the available information there are two reasonable possibilities on what is going on.

1. As Dr. House used to say in the eponymous TV show, you are reporting your mistaken diagnosis of the disease, not the actual symptoms. Let's try getting the facts straight. What is the size of every part file you have? What is the total size of the backup archive parts? What is the total size of the files extracted? How many files were extracted? Do you have any zero-sized files? Which exact version of Akeeba Backup did you take this backup with? All of the above are unbiased data which will help us figure out what is going on.

2. If you are trying to extract on Windows please note that not all valid Linux filenames are valid on Windows due to Windows restrictions (official MSDN page on the subject). For example, if any of the directories or the filename itself contains any of the characters <>:"/\|?* or unprintable ASCII 0 to 31 then the file cannot be created on Windows (even though it's perfectly valid on Linux, macOS and pretty much any other operating system except Windows, DOS and their variants). The default behavior of eXtract Wizard is to "Skip most errors" i.e. skip over files with invalid filenames instead of throwing an error and stopping the extraction. If you believe this is the case disable the Skip Most Errors checkbox and try extracting again. You'll get an error which tells you what cannot be written to disk. However, this is NOT a bug and you can't do anything about it except trying to extract the backup archive on a Linux server.

Please note that #2 is actually very common when you're using subpar FTP software to upload files from a Windows computer to a Linux server. I've seen many times duplicated folder structures on the remote server with a root folder named "C:". This is an invalid folder name on Windows so it can't be extracted. It is also leftover / unused data which shouldn't be on your server anyway (junk).

Please let me help you and keep an open mind. I have already told you that your question, as it was framed, was invalid. I explained why. I DO believe you have an issue that needs to be addressed. However, it's not what you think it is. Please let me help you first identify the problem and then come up with a solution. Don't ask me, repeatedly, to help with an imaginary issue which we've established cannot occur because, frankly, I can't help solve imaginary issues but I'm really good at solving real ones ;)