Support

I am going to publish version 3.2.b1 tomorrow which fixes this issue. Alternatively, if you do not wish to upgrade to the beta release just yet, you can enable count quotas and use a count quote of 1 as a workaround.

The timeout error during FTP transfer could also cause the non-deletion to happen. The sequence of operations is take the backup, mark the backup as complete ("ok" status), send the files to the remote location, delete the local files, update the backup entry noting that the files have been removed ("obsolete" status).

In order to avoid the timeout during file transfer, you can use split archives. This will cause the backup archive to be split in multiple files. Just go to the Configuration page, find the Archiver Engine row and click on the "Configure..." button. Drag the "part size for split archives" slider to a setting around 700Mb and save your configuration. The result will be a backup split in two files, with extensions .jpa and .j01 (if using the JPA format) or .zip and .z01 (if using the ZIP format). When you need to restore that archive, just download both parts so that Kickstart or Akeeba eXtract Wizard can locate and extract them. So simple!

There is exactly one source of timeouts: the value of PHP's max_execution_time. All web software is bound by its limits. Akeeba Backup tries to chunk the backup process to individual steps. The shortest duration possible is that of an atomic operation, i.e. an operation which can't be further cut to smaller pieces. If this is too long when compared to max_execution_time, a timeout occurs.

Transferring files by FTP is an atomic operation. Most FTP servers I have encountered do not support multipart uploads (or, more correctly, appending to existing files). Moreover, PHP doesn't support appending to existing files over FTP unless your host allows the ftp fopen() wrapper. According to harsh experience, the chances of something like that working range from abysmal to outright impossible, hence I never tried to make use of that PHP feature.

Thereofre, the only possible and reliable workaround is splitting the archive file, making each atomic operation last less than the max_execution_time. This is actually what is already documented, albeit the documentation tries to give an explanation in layman's terms of what is going on and why you need to do that.

I agree with you, but both changes are impossible to do.

1. PHP won't let me know why the timeout occurred. At best, if the FTP transfer times out because of a network or server issue, it will return "false" (that's all the information it gives!!!) and I'll issue a warning stating that the upload was impossible. I am telling you as much as PHP lets me know ;) If it is a PHP timeout, the causes can be numerous. Analyzing them would take a lot of code and a lot of time. However, as soon as PHP times out, it only gives me a few milliseconds to shut down the process gracefully. All I can do in this timeframe is to put a notice in the log that the backup timed out.

As a result, I can't do anything about that. The user has to read the manual and follow its troubleshooting instructions. Think the car analogy. Modern cars light up an engine icon which, according to the manual, means "Go to your mechanic a.s.a.p.". The causes of this could be numerous, but your car won't tell you. The car's computer keeps a log and your mechanic can read it and tell you what's wrong.

2. Since Akeeba Backup offers many different functionalities and different alternatives for accomplishing similar goals, a functional diagram would be so convoluted that most users would perceive the software as byzantine upon setting eyes on it. To my defense, many people use OpenOffice.org Writer or Microsoft Word. They would have equally and even more complex functional diagrams, yet people find their way through them. So, I think I'd better stick to not having to build a workflow chart as it would ultimately confuse most users.