Support

Your backup is a multi-part, i.e. it consists of several files which have the same base name but different extensions. Assuming a JPA backup archive, the file extensions would be .jpa, .j01, .j02 and so on.

You need all of the files to be present to successfully restore such a backup archive. Please remember that these are not different archives, they are merely parts of the same backup archive.

Think of it like War and Peace. If it was printed in a single book the resulting tome would be too heavy and awkward to use. Therefore, it is usually printed in two books, Volume I and Volume II. You can not read them separately and make sense of Tolstoy's masterpiece; you have to read both of them, sequentially, and in the right order.

It's exactly the same with backup archives. When they are too big you cannot have them in a single, massive, awkward file; you split them into multiple files. The order these files are read are .j01, .j02, ...., .jpa (the .jpa file is the last volume of the multi-part archive).

If you only have the last volume, .jpa, the restoration script cannot make sense of it much like a reader only given Volume II of War and Peace would have no idea what is going on and give up in frustration.

Are you trying to restore the backup through the backend of your site, or via Kickstart?

There's a reason I'm asking. I will need to get a detailed log of what is happening during extraction. Each of these methods has a different way of being asked to produce a log.

Edit your kickstart.php file (or whatever you have renamed it). Towards the top you will find the line

//define('KSDEBUG', 1);

Change it so that it reads (remove the first two slashes):

define('KSDEBUG', 1);


Now proceed with trying to extract the backup archive. It will generate a file called debug.txt.

Put this file in a ZIP archive and attach the ZIP archive to your next reply. Only you and me can see it, even though this is a public ticket. It will help me understand what is going on under the hood.

It looks like you have hit a hard limit.

The file that fails to extract is CentOS-7-x86_64-Everything-2009.iso. I am not putting the full path here because it's a public ticket; you can see the full path 20 lines before the very end of your log file. That's a 9.5GiB file as far as I can tell.

The JPA format uses 32-bit unsigned integers to express the file size of each file. This allows for files up to 4GiB to be stored in the archive. Your file is more than twice as big, leading to an overflow. This breaks the archive file headers, therefore the extraction.

Right now, the only thing you can do is exclude this file (and any other over 4GiB files) from the backup archive. Even if we revise the JPA format to use 64-bit integers (allowing file sizes up to 16 EiB) I think you'd have a very inconvenient site backup as it would be incredibly big for no good reason. A 10GiB file which will never change and can be easily obtained from a different mirror is best excluded from the backup, with a note on where to retrieve it from, or kept on its own in some off-site storage if you really don't trust that any of the hundreds of CentOS mirrors will be available in the future.