Support

Hello Donovan,

you didn't set any part size for your archive.
This means that Akeeba Backup tries to upload the whole backup (more than 35Mb) in one shot: if such operation takes too long you get a timeout error.
Please try to setup a partsize of 10Mb and try again, that should do the trick.

No, you can't have different quotas.

Regarding the corruption problem, let's do some debugging.

1. Remove any post-processing engine and try to download and extract the copy saved on your site, is that valid or it's corrupted?
2. Try another post processing engine, for example Dropbox, is the backup still corrupted?
3. Try to use JPA format and Dropbox, is the backup still corrupted?
4. Try to use JPA and FTP post processing engine, is the backup still corrupted?

Let me know the results of your tests, depending on your answers we can narrow down where the problem occurs

Ok, so the problem is in the files included in the backup, not the transfer.
This is caused by a file that shrinks during the backup process. 99% of times they are log files: when the file grows too large, it gets truncated and then new data is appended.
This process is breaking the whole archive, since the recorded size while the backup starts and the real size are different.

You can do this to narrow down the issue: download a backup archive and try to extract it. First try to check the option Ignore most errors inside Kickstart, if you're lucky that could do the trick.
Anyway, we really want to exclude such nasty file from your backup, so do the following steps:

1. Download your backup archive
2. Edit the kickstart.php file and uncomment the line that contains define('KSDEBUG', 1);
3. Run the extraction
4. Kickstart will produce a massive debug file, logging all the actions it's doing.
5. Scroll to the end of the log file, the second to last file is the corrupted file (or the last one, I can't recall ATM). Note it down
6. Go inside your Akeeba Backup installation and exclude such file from the backup

That should do the trick, please let me know if your backups are still corrupted.

DO NOT USE THIRD PARTY UNARCHIVERS TO EXTRACT THE ZIP FILES. We have already documented this! There are two reasons why you should NOT do that:

1. Standards-compliant multipart ZIP archives ARE NOT supported by most third party unarchivers. Akeeba Backup always generates this kind of backup archives since it's impossible to tell at the start of the backup whether we'll need to create a single or multipart archive. Only PKZIP for Windows and WinZIP –both developed by the inventor of the ZIP format– support this kind of archives. All other third party unarchivers are based on the third party InfoZIP library which erroneously doesn't support this kind of files, reporting them as corrupt.

2. PHP cannot calculate the CRC for larger files (where "larger" for PHP is generally anything over 1Mb long) because that would cause a memory outage error. As a result files of that size will have a CRC of 000000 which is, of course, invalid and makes third party unarchivers to mistakenly report the archive as corrupt.

This is why we tell you to always use Akeeba Kickstart or Akeeba eXtract Wizard to extract the backup archives. Alternatively, you can use PKZIP for Windows or WinZIP always bearing in mind that any reported "corrupt files" are, in fact, not corrupt at all.

Regarding the possibility of having a corrupt backup archive it is extremely rare and will only happen if the file being backed up disappears or shrinks dramatically in size while the backup is in progress. This is NOT something that happens regularly and we DO have workarounds in place to prevent the archive from being corrupt. These workarounds depend on the ability of your server's filesystem to notify PHP about the size change in a way which allows us to enforce said workarounds.

If you want to make sure that the multipart archives can be extracted you can use the archive testing feature in Akeeba Backup itself. Go to the Configuration page, check the "Archive integrity check" check box.

If you want to do test restores (recommended!) you can use Akeeba UNiTE. Access to it is included in your subscription. This is a command line PHP solution which allows you to automatically extract and restore a site backup archive. Incidentally this is what we're using at the office server to test our backups every day :)

If you want a command line extraction-only solution you can still use UNiTE with a custom execution chain that only goes through extraction. It is feasible and documented but I don't see why bother doing that when it's equivalent to the archive integrity check in Akeeba Backup, the latter being far easier to use as well.