Akeeba Backup for Joomla!

Wednesday, 23 November 2011 05:19 CST

user37365

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the forum before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: (1.5)
PHP version: (5.2.17)
MySQL version: (unknown)
Host: (Godaddy Vserver)
Akeeba Backup version: (unknown)

EXTREMELY IMPORTANT: Please attach your Akeeba Backup log file in order for us to help you with any backup or restoration issue.

Description of my issue:

Hello. I am trying to backup one site and it always throws the AJAX error. I have read the troubleshooting but I cannot find the solution for this. Attached is the LOG file.

Many thanks for your support!

Antonis

Wednesday, 23 November 2011 05:26 CST

nicholas

I know that GoDaddy applies a maximum CPU usage limit which could cause it to kill the backup in mid-process. So, let's try the following fine-tuning settings:
- Minimum execution time: 5 seconds
- Maximum execution time: 3 seconds (yes, max is lower than minimum)
- Bias: 50%
and retry backup.

If this fails, please check the free space on this account. I'd recommend having at least 50% of your disk quota free before trying to backup that site.

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, 23 November 2011 05:34 CST

user37365

Hi Nicholas,

Many thanks for your prompt reply! I tried that but still got the same error at about 73%. Here's the LOG file once more.

BR,
Antonis

Wednesday, 23 November 2011 05:38 CST

nicholas

OK, this time it went further. This means we tricked the CPU usage limit, but we have to try harder. Humph! Let's try some even more conservative settings:
- Minimum execution time: 7 seconds
- Maximum execution time: 3 seconds (yes, max is lower than minimum)
- Bias: 50%

If that still fails, please do check you available disk space on the server and tell me how much is consumed (something like "100Mb of 500Mb available") - and post the new log file, of course.

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, 23 November 2011 05:39 CST

user37365

Actually it was 73% last time as well :) I am re-trying it now with your suggestions.

BTW 561 MB used of 10.0 GB, is my disk usage.

BR,
Antonis

Wednesday, 23 November 2011 05:41 CST

nicholas

Don't trust the percentage! As I explain in the documentation, it's a fuzzy number as we can't know beforehand how many files and directories we have to process. The number may jump between 50% and 75% in a full site backup. I am taking a look at how many files have been processed as per your log file ;)

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, 23 November 2011 05:48 CST

user37365

OK tried the new values. There was 7.5 only not 7 for the min. execution time so I selected that. Same problem though...

Attached the LOGS.

Antonis

Wednesday, 23 November 2011 06:01 CST

user37365

If it helps, I also just tried a min.execution of 10 and attached the logs once more.

Antonis

Wednesday, 23 November 2011 06:06 CST

nicholas

Hm, it always seems to halt when the backup engine is trying to backup a few files at once :s We can try the following settings:
- Minimum execution time: 3 seconds
- Maximum execution time: 1 second
- Runtime bias: 50% (or try to set it as low as it gets)
If this still fails, you will have to ask GoDaddy if the script is being killed due to CPU usage limits and, in this case, increase the limit a bit because it's not really usable :(

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, 23 November 2011 06:09 CST

user37365

The thing which i notice Nicholas, is that sometimes when i click Backup, it immediately shoots the error, and then when i retry it start the process and stops after a while...

Wednesday, 23 November 2011 06:11 CST

nicholas

This is because of the CPU usage limit. The backup uses a lot of CPU power, GoDaddy detects that, kills the script and will refuse to reload that URL until a specific "cool-off" period has passed. Did I mention that GoDaddy is one of the most unreliable hosts?

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, 23 November 2011 06:17 CST

user37365

Yes, I'm am realizing that they are not as good as I thought they were.

I am on the chat with them now and they are telling me this:

"You would need to modify the script to limit the amount of memory it is using. That is not something we can assist you with in any way, as we do not assist with scripting."

Wednesday, 23 November 2011 06:30 CST

user37365

Nichola, i have no idea what happened but it worked! here is the log once more.

I will tell you something i did and I have no idea if that made the difference.

I completed removed the .htaccess file, tried it and still didn't work. I then created a new .htaccess file using Admin Tools, re-ran the Akeeba configuration test and ran the backup. Could that be the issue?

BR,
Antonis

Wednesday, 23 November 2011 11:51 CST

nicholas

It could be. You can actually override PHP configuration parameters in the .htaccess file. Maybe an unfortunate override caused the problem?

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, 23 November 2011 12:01 CST

user37365

No idea Nichola. I noticed that it does it again. So sometimes it works sometimes not...

Wednesday, 23 November 2011 12:03 CST

user37365

It should be something with the server, but Godaddy say the CPU shouldn't be an issue...

Wednesday, 23 November 2011 12:26 CST

nicholas

It's certainly something with the server. The fact that it worked once means that the limiting factor is how busy the server is. Having seen the max amount of RAM allowed and the max execution time, neither of these can be the cause (despite what GD "tech support" said). It's not the amount of free space either, you have plenty of it. It's not a PHP error, or it would be reproducible and always crash at the exact same point (right now, every time it crashes when backing up a different file). Therefore the ONLY thing we can not rule out is a CPU usage restriction.

Can you please ask GoDaddy to escalate your issue so that you get to talk with a real engineer? The first level of tech support is usually the less capable of answering such tickets :(

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