Support

Sorry for the delay, I thought I had replied to your ticket :s

I believe that you need to disable multipart uploads for S3 and set a smaller part size. Please see the last three paragraphs of https://www.akeebabackup.com/documentation/troubleshooter/abamazons3.html

Nope, you have not disabled multipart uploads for profile #3. Here's what tells me so:

INFO |130225 18:01:39|Continuing post processing file /home/macaucen/public_html/administrator/components/com_akeeba/backup/site-www.macaucentral.com-20130226-000002.jpa
DEBUG |130225 18:01:39|S3 -- Uploading part 1 of K7aAtfe4tAyBmeBaAcVyySPMxj5OcL_ZzpNywscKpPUFJm4Xz0GSNpAKkcyOeuTsv12KuQyTPkIf9ZLt6yytaf8cxXiPebf.PTdOQn7iqWY-

I believe you were editing the settings of the wrong profile. Profile #3 still has multipart uploads enabled.

Not according to your log. It stated that profile #3 was being used.

There seems to be a server timeout while uploading the second part file to Amazon S3. I'd go with a smaller part size of 20Mb.

Can you please attach the new log file?

The last log line solves the mystery:

DEBUG   |130302 13:30:38|-- Adding mccrm/custom/k/extjs4/resources/themes/images/gra

See how it's cut off? This can mean only one of two things:

• Your server has a file size limit (not advertised anywhere). If a PHP script tries to create a file bigger than that, it is terminated by the server. I don't think this is the case because you could previously create single part backups of several dozens of Megabytes. So, this leaves us with the other issue and the diagnosis of the root cause:
• You are running out of free disk space. Try removing the contents of your backup output directory. Delete everything inside administrator/components/com_akeeba/backup except the .htaccess and web.config files. If this problem persists, please contatc your host and ask them to increase your site's disk quota.
  IMPORTANT! I've seen hosts which claim "unlimited" or outlandish (e.g. 100Gb) of disk quota. What usually happens is that they give you a limited amount (e.g. 500Mb or 1Gb). When you run out, you have to ask them for more and they'll give you another 500Mb or 1Gb of space. Repeat until you have adequate free space.

According to your log, my diagnosis and your tests the problem IS free disk space. Just because you have, say, a 3TB HDD doesn't mean you have ample space for a website.

On Linux and all UNIX derivative operating systems there's something called "user limits" a.k.a. "quotas". If the system administrator has given you a quota of 1Gb, no matter how much space you have on the HDD you will always be able to use exactly up to 1073741824 bytes, not a single byte more.

Conversly, if you are given a quote of 100 Pb (petabytes) this won't of course cause the HDD to grow beyond its size to accomodate your quota. If your control panel reads the quota limit and your current usage to calculate your kind-of "free disk space" it will lie profusely in such a case.

So, let's reitterate the known facts:

• The next backup fails. This means that you are running out of disk space / quota.
• The log file of the failed backup is truncated. This means that you are running out of disk space / quota.
• One backup works. As a result there is no bug or compatibility issue with your server. If there was, no backup would ever complete. This means that you are really running out of disk space / quota.

As a result, the new diagnosis is the same old "you are running out of disk space / quota". At least you now know the two most common cases of why that could happen.

I'm closing this ticket. There is no point saying the same thing for the third time. It's cause and effect. If you have an alternative explanation, follow your hunch.