Akeeba Backup for Joomla!

Monday, 07 October 2013 14:21 CDT

Machiel

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 2.5.14
PHP version: 5.3.27
MySQL version: 5.5.27
Host: Neostrada.nl
Akeeba Backup version: 3.8.2

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:
I'm using dropbox as my post processing file handler. The backup works great and all the files are transfered to the temporary location. When upload to dropbox starts te first 3 or 4 files(each 25MB) are uploaded fine. After that there's an internal server error / ajax loading error.

First noticing this error I've read the other postings over here and tried reducing the file size(to as little as 2 mb). That didn't work great because I still get the same error. The uploaded files are deleted from the server. The files not uploaded to dropbox are still there. So there's seems to be going something wrong during the transfer.

I'm using the jpa file format, php memory limit is set to 265mb, max execution time is 600. I've plenty of disk space on my server(just 10% used). Dropbox available space is about 60GB and i'm trying to transfer a +/- 400mb backup.

I hope you can help me with this one.

Thanks in advance
Kind regards
Machiel

Monday, 07 October 2013 22:44 CDT

dlb

The Internal server error should leave an entry in your server error log - not the same as your access log. The error log is sometimes available through your host interface, sometimes it is a file or folder in the root of your site. It varies by host, so I can't help you much in finding it. Your host's support staff can tell you where to look for it. The entry in the error log will tell us what interrupted the job.

Dale

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Tuesday, 08 October 2013 01:38 CDT

Machiel

Hi Dale,

Thanks for your reply.
The server error log just reports the following:

[Tue Oct 08 08:24:01 2013] [error] [client 212.178.108.34] File does not exist: /home/brinkm1b/public_html/500.shtml, referer: http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup

The server raw access log reports this:

212.178.108.34 - - [08/Oct/2013:08:23:28 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 200 229 "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
212.178.108.34 - - [08/Oct/2013:08:23:34 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 200 268 "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
212.178.108.34 - - [08/Oct/2013:08:23:42 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 200 259 "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
212.178.108.34 - - [08/Oct/2013:08:23:44 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 200 277 "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
212.178.108.34 - - [08/Oct/2013:08:23:49 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 200 279 "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
212.178.108.34 - - [08/Oct/2013:08:23:52 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 200 266 "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"
212.178.108.34 - - [08/Oct/2013:08:23:58 +0200] "POST /administrator/index.php?option=com_akeeba&amp;view=backup&amp;task=ajax HTTP/1.1" 404 - "http://www.brinkmedia.nl/administrator/index.php?option=com_akeeba&amp;view=backup" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.66 Safari/537.36"

In my opening post I forgot to mention this error occurs to me at 3 joomla websites running on 1 and the same webserver.

I've also tried to reconnect dropbox again with the step 1 and step 2 options but that didn't succeed as well.

Tuesday, 08 October 2013 08:35 CDT

dlb

Machiel,

Is that all that was in the sever error log? The line you posted is telling us that it can not find the pretty Error 500 error message file, 500.shtml. There should be another line that actually tells us why the 500 occurred.

It takes about a minute to transfer each of the first three archive parts, the fourth part fails. My first thought was to reduce the part size, but you have already tried that.

Dale

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Tuesday, 08 October 2013 09:08 CDT

Machiel

Dale,

That's indeed all there is in the error log. It's indeed kinda strange but it's the cpanels error log. Can't find any other error log.

I've attached a new attachment which contains a screenshot of the error( perhaps you find something weird over there). Besides the screenshot I've attached debug logs of the 25MB setting and one of the 2MB setting.

Thanks
Machiel

EDIT 08-10-2013, 14:23 UTC:
In the mean time i'm trying to reach my host to see if I can get a more detailled error log or something like that.

Edited by Machiel on 2013-10-08 09:24 CDT

Tuesday, 08 October 2013 09:24 CDT

dlb

Time to call out the big guns. :-) I asked Nicholas to take a look at this.

Dale

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Tuesday, 08 October 2013 09:28 CDT

nicholas

Your host has a very tight CPU usage limit. I can see that after a while it simply kills the backup process. You can try using a small part size for split archives (2Mb) and also use these settings:

- Minimum execution time: 5 seconds
- Maximum execution time: 3 seconds (yes, max is less than min, it's not a typo)
- Runtime bias: 50%

This will make the backup dead slow and MAYBE you will be able to upload the backup to Dropbox. I am not very optimistic about it after seeing your log file with the 2Mb part size. It seems that a couple of page loads taking more than 5 seconds are enough to have your host kill the backup :(

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 08 October 2013 10:00 CDT

Machiel

Thanks for your response Nicholas.

You are right not being optimistic, it is indeed dead slow, but in the end the backup is completed but I just get the same error after a few uploads to dropbox.

I think it's time to confront my host with this problem. Do you have some figures or some tests so I could explain the problem a bit more detailed to them?

Do you have any other advice about transferring the backup from the server to a cloud storage server? Are there significant changes in Akeeba's transferring methodes in the last month or so(that's when I first noticed not all the files where transfered to dropbox)?

Tuesday, 08 October 2013 10:57 CDT

nicholas

> I think it's time to confront my host with this problem. Do you have some figures or some tests so I could explain the problem a bit more detailed to them?

Unfortunately no. I know that the problem is their CPU usage limits based on experience. Also based on experience I am quite sure they won't change them for you. In fact they can't change them for you, they have to change them on the entire server and that's a huge problem for a shared host. It doesn't hurt to ask them, but I'm afraid it will come down to either not uploading your backup to remote storage or using a different host.

> Do you have any other advice about transferring the backup from the server to a cloud storage server? Are there significant changes in Akeeba's transferring methodes in the last month or so(that's when I first noticed not all the files where transfered to dropbox)?

None at all. There can't be any changes, not unless a storage service provider changes their API.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 08 October 2013 12:11 CDT

Machiel

Nicholas, thanks for answering and trying to help.

I'm going to contact my host and hopefully they will help me. Until a month ago it worked perfectly for over 1,5 years so kinda strange it stopped working properly.

Just for me to better understand the actual problem and to explain it to my host. Why is the CPU usage limit the problem? It seems to me that generating the backups files themself(JPA files) is more CPU intensive than just uploading them to dropbox? Or am I wrong on this one?

Tuesday, 08 October 2013 14:13 CDT

nicholas

With the settings I gave you we reduced the duty cycle of the backup process to ~40%. The backup is running for about 2 seconds, sits doing nothing for 3 seconds, repeating this until the backup is complete. Uploading, however, cannot be slowed down. The time it takes to upload something depends only on its size and the speed to the remote host. This means that the upload process has an 100% duty cycle (it fully utilises CPU and bandwidth throughout its run time). This might trigger a very sensitive CPU usage limit.

CPU usage limits are not static on a server. I mean that they are not set once and left untouched forever. As the host is putting more sites on a single server the server utilisation goes up. In order to prevent the server from slowing down to a crawl the host has to either buy more servers (less sites per server = better performance) or make CPU usage limits more strict (less time spent per each site's page load = more sites on the server with a steady performance). The problem with the firsts approach is that it's expensive and requires highly skilled system administrators to make it necessary as little as possible. The second approach is much simpler, but it screws customers. So it comes down to whether the host wants to invest in customer satisfaction or make a quick buck. I've met both kinds of hosts. The former are marginally more expensive (about $10-20 per year more expensive, that is) and are generally considered stellar hosts. The latter are the majority, they are typically cheaper but you have to spend a lot of time working around their restrictions. In the end of the day the cheap host costs about 10x as much as the "expensive" host, but I digress.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 09 October 2013 01:15 CDT

Machiel

Nicholas, thanks for the in depth explanation about the duty cycles and CPU usage. I've contacted my host and I am waiting for them to respond(probably later this morning).

I fully agree with you about cheap hosts. A few years ago I was using one of those cheap hosts, with a lot of restrictions and bad support. My current host doesn't have (or had) those limitations and has great support, so I guess we will come to a solution so I can transport my backups to a cloud service.

I will keep this post updated about my findings, and perhaps an in depth error log if the host can give me something like that.

Wednesday, 09 October 2013 15:08 CDT

Machiel

I've contacted my host and they fixed it. They didn't limit the CPU usage more than they allready did. But they did change a setting which sets the total time a script is allowed to run. They have changed that setting and everything works as before.

Nicholas and Dale thanks a lot for your support and guiding me in the right direction.

Thursday, 10 October 2013 02:03 CDT

nicholas

> They didn't limit the CPU usage more than they allready did. But they did change a setting which sets the total time a script is allowed to run.

That was what I was talking about. I am glad your host reacted swiftly and efficiently!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support