Support

First, upgrade to Akeeba Backup 3.3.b1. As soon as you install it and try to access it, the post-installation configuration page appears. Make sure the "Run the Configuration Wizard" box is checked before you save your settings.

Once the Configuration Wizard finishes its run, go to Akeeba Backup's Configuration page and set the following settings:
- Minimum execution time: 0.5 seconds
- Maximum execution time: 7 seconds
- Runtime Bias: 75%

If these don't work, try reducing the maximum execution time to 5 or 3 seconds.

If all else fails, make sure that you have covered all the steps listed on the troubleshooting page and if it still won't work, please ZIP and attach the latest log file. Remember to tell me what you have tried so far so that I don't ask you to try something you've already did but didn't work. Thank you!

Hi!

Watching your log file I realised that you are trying to send your site to another server, either using the Site Transfer Wizard or the DirectFTP backup engine. In any case, it seems like the remote FTP server stops responding after a while, causing the backup failure.

Please try taking a normal backup, with the JPA or ZIP archiver engine, instead. Then, you can upload that backup archive to the remote server and use Kickstart to extract it.

OK, fair enough. Let me explain what the problem is. In order to avoid server timeouts, we have to split the backup process in several "chunks". Each one of them lasts 5-14 seconds under your current configuration. At the start of each "chunk" (called a "step" in Akeeba Backup jargon) we have to open a new FTP connection and shut it down at the end. This can cause the following issues:
- The remote FTP server may not be very fond of the same IP address opening and closing connections all the time, eventually refusing us further connections.
- Due to the synchronous nature of PHP's FTP feature, we can not send keep-alive commands while the file transfer is in progress, unlike desktop FTP applications. As a result, the remote FTP server may simply close the command channel (i.e. the connection), refusing any further file transfers.

In your case, it seems to be the latter issue. One way to work around it is to go to Akeeba Backup's Configuration page and set the following options:
- Minimum execution time: 1 second
- Maximum execution time: 3 seconds
- Runtime bias: 75%
This will make your backup dead slow, but may work around the issue with the FTP server shutting down its command channel. However, it may trigger the first issue, with the FTP server forbidding too frequent connections.

Well, it is neither a host issue, nor a badly written script issue. It's PHP. It's synchronous and it times out. You can't do otherwise. While PHP is extremely good at transferring a couple of files at a time -mostly used to transfer one small file at a time- we try to make it transfer an entire site. This can't be bulletproof and we can't guarantee that it will work trouble-free all the time, as we are stretching PHP to do something it's not really designed to do.

Please note that if this won't work, there is a workaround. We can always use a regular backup and the "Upload to remote FTP server" data processing engine. This will transfer the backup archive to the remote server. So, all your client needs to do is to upload kickstart.php to the target server and run the restoration. Uploading one file is not exactly rocket science and fairly trivial compared to the rest of the restoration process, so I don't consider that this alternative is overly difficult when compared to the Site Transfer Wizard.