Support

First, let's try making sure that the SSL setting doesn't cause the problem. First go to Akeeba Backup's Configuration page and find the "Data Processing Engine" drop down. Click the Configure button next to it. A new pane opens below. Find the "Use SSL" checkbox and make sure it is not checked.

The second thing you have to check is that your host's firewall allows access to Amazon S3. Ask them if they have a firewall which blocks outgoing connections. In this case, please tell them to allow TCP/IP connections to ports 80 and 443 of s3.amazonaws.com. If they request an IP, please tell them that this domain name is a multicast one and they have to run "host s3.amazonaws.com" from their server to obtain the IP. It doesn't matter if this sounds like Chinese to you, your host's support technicians will understand (or should, at the very least).

Finally, some hosts do not play very well with Amazon S3's multi-part upload feature which allows us to upload a very big archive file in 5Mb chunks. In this case you will have to follow Plan B which is to have Akeeba Backup split the archive file in small chunks, one file per chunk, and then upload each of those chunks in one go. This is a two-legged solution.

For the first leg of the solution, please go to Akeeba Backup's Configuration page and find the "Data Processing Engine" drop down. Click the Configure button next to it. A new pane opens below. Check the "Disable multipart uploads" option and make sure that the "Process each part immediately" option is not checked.

Now, for the second leg, we have to do some trial and error. Still in Akeeba Backup's Configuration page, find the Archiver Engine drop-down and click on the Configure button next to it. A new pane opens below. Find the "Part size for split archives" option and select the 49.99 option. Try a new backup. If it crashes while uploading files to Amazon S3, go back to this option and try smaller values, i.e. 20, 10, 5, 2 or even 1, trying a new backup after setting each one of those values.

Please let me know how it went!

Side note: You said that your log file is 15Mb long. It sounds like you have a gazillion files in there! If there are files or directories which need not be backed up (e.g. additional sites on subdomains which should be backed up on their own right) please use the Files and Directories Exclusion feature of Akeeba Backup to exclude them from the backup.

Yes, that's correct. The problem seems to be with some buggy versions of curl. Some versions of curl work just fine, some routinely crash when dealing with large files. Most likely your host did a minor server upgrade which replaced curl and caused this issue to manifest itself. Apart from the multi-file approach, I can see no other alternative :(

If you're using backup.php to run your CRON jobs, it will automatically print out any warnings. If there are warnings, it will print out a very prominent block which notifies you that the backup completed with warnings. The CRON daemon takes the output and emails it to you (if you haven't set up the email notifications on your host, do it now). So, the reliability issue is now a matter of simply creating email inbox rules to archive the email notifications of successful backups and mark as important the emails of backups which completed with warnings. Easy-peasy :)