Support

Well, it's quite obvious:

INFO    |131009 18:13:22|Preparing to post process site-www.wichitaharvest.com-20131009-130851.j04
INFO    |131009 18:14:39|Successfully processed file site-www.wichitaharvest.com-20131009-130851.j04

Uploading the backup part file takes 77 seconds. You maximum execution time is 30 seconds:

INFO    |131009 18:08:51|Max. exec. time    :30

Therefore you have a PHP timeout error. Please read the information in https://www.akeebabackup.com/documentation/akeeba-backup-documentation/step-by-step-guides.html#how-to-cloud-backup-basic-config and adjust your backup part size to a lower value (about a third of what you have right now should work).

As I wrote:

adjust your backup part size to a lower value (about a third of what you have right now should work).

A third of 150Mb is 50Mb, not 100. I didn't mean reduce by a third, I meant (and thought it was quite clear) that you should reduce to a third of the original value. I guess my message was a bit ambiguous. Therefore I'd suggest trying to reduce the part size to 50Mb (which already veers dangerously close to the timeout threshold) or, if that fails, reduce it to 20Mb.

I observe something very disturbing in your log file. First let me give you an executive summary of how the backup works.

Backing up the entire site is a time and resource consuming operation. If we tried to backup the entire site in a single page load we would run out of memory, out of time or otherwise the host would kill the backup process. This is why the backup process is split into several steps, each one occurring in a separate page load. Since it is very annoying (and very time consuming) having the page endlessly reload we are doing these reloads in the background using XMLHttpRequest, commonly referred to as "AJAX" (Asynchronous Javascript And XML – even though nowadays everyone, including us, is using JSON instead of XML making this a misnomer).

The log file notes when each step begins with a log entry like this:

DEBUG   |131011 12:17:50|====== Starting Step number 59 ======

Normally there is exactly ONE log line with the same step number. The step number is a counter which is increasing monotonically, i.e. 1, 2, 3, 4 and so on.

In your log file I see TWO log lines with the same step number. This means that your browser is not working properly and sends TWO requests for the same step, two seconds apart. This slowly corrupts the backup up to the point the backup completely crashes. This is an extremely rare condition which is not due to a bug in our software. The very few times (counted in the fingers of one hand) I have seen this it was a problem with a browser extension, a misbehaving antivirus / Internet security / firewall product or a misbehaving proxy along the path to the web server.

I would STRONGLY recommend using a different browser, on a different computer, on a different Internet connection to run your backup again. If your backup still crashes check for duplicate "Starting Step number" log lines (the step number is the same in two or more such lines but the time is not).

Unfortunately I can't do anything else to help you. This problem is not due to something in our code or something I can instruct you how to fix.