Support

ZIPping and attaching the backup log file will help you get an answer much faster than crying help ;) The truth is that without the log file we have no idea what went wrong and can't help you. So, attach the log in here and we'll help you!

Some hosts intentionally limit the length of files which can be written to by PHP. These are arbitrary limits with most common values being 10Mb (Strato.de/.eu), 5Mb (a few lesser known hosts) and 2Mb (000webhost.com). The good news is that we have a workaround for this case.

Go to Akeeba Backup's Configuration page and click the "Configure..." button next to the Archiver Engine drop-down. A new pane opens below. Find the "Part size for split archives slider" and click on it. Use your arrow keys to fine tune the setting to 10Mb and, if this doesn't work, also try 5Mb or 2Mb. Make sure you are tweaking the correct slider. Do not touch the other two below this one. Save and retry backing up. If this still doesn't work and comes back with the exactly same error message, you can try lowering that setting even more. Some hosts (usually the free ones, like FreeHostia) have even smaller limits, e.g. 500Kb.

There is also one more potential issue, the time limits used by default by Akeeba Backup. Go to your Akeeba Backup Configuration and scroll to the bottom of the page. Set the following configuration settings: 
- Minimum execution time: 1 second
- Maximum execution time: 7 seconds
- Bias: 50%

If these don't help, also try switching to the JPA archive format, as it is less CPU intensive than the ZIP format.

If all of these do not have any effect, please ZIP and attach the new backup log. Thank you!

There is also a reason for this issue. The ZIP format requires calculating a hash (CRC-32 sum) for each file. This is a CPU intensive process which can cause a timeout error or a CPU usage limit exhaustion error. The JPA format is much less CPU intensive and has a better chance of succeeding, even in the more restrictive hosts.