Akeeba Backup for Joomla!

Thursday, 12 June 2014 10:38 CDT

GJSchaller

I am receiving the error "Failed Smart algorithm on AECoreDomainDb" when attempting to back up my site. I've run the configuration wizard, set the min / max times to 1 & 7, set the JPA file size to 10 MB, and ALICE is not showing any issues (There had bee one or two earlier that I excluded the issues / resolved).

The site is on the same VPS as several others, all of which backed up without issue. This site is (of course) the largest of the set, with an active Kunena forum, and large JoomGallery photo gallery.

Issue was happening on Akeeba Backup 3.11.1, I was attempting to back up before upgrading to 3.11.2 and Joomla 2.5.21. :-) Upgraded to Akeeba Backup 3.11.2 to try an resolve the error, but no luck.

Occasionally, it gets past backing up the DB, but then gives a 500 error while backing up the files.

Log is attached. Additional info can be viewed at: http://www.knightrealms.com/phpinfo.php

Thank you for your help!

Thursday, 12 June 2014 10:39 CDT

GJSchaller

Argh, re-attaching log. Everyone wants a Log!

Thursday, 12 June 2014 10:39 CDT

GJSchaller

One more try....

Thursday, 12 June 2014 11:41 CDT

GJSchaller

A manually run cPanel backup also failed due to file permission issues, which lead me to look at Google PageSpeed's settings on my site.

It looks like there may have been an issue with SiteGround's caching systems - somehow, two conflicting caches were turned on at the same time.

As soon as I can make a good manual backup using cPanel, I'll try again using Akeeba.

Thursday, 12 June 2014 11:49 CDT

nicholas

I am not sure if you have a corrupt database table, if you are running out of disk space or if you have a permissions issue..

First make sure that you can take a cPanel backup and all permissions are set up properly. Obviously, if the permissions are off (or if they are modified on the fly) the backup will fail and the failure would be consistent with what we see in the log file.

Then check your available disk space. Better yet, ask Siteground if you're over the quota. Do not trust what cPanel tells you, its usage stats can be up to 6 hours out of date. I've learned that the hard way :(

Since you are on Siteground the best settings for taking a backup are:
Minimum execution time: 0
Maximum execution time: 20
Runtime bias: 75%

You needn't use a small part size, SiteGround doesn't have this kind of restrictions. A part size of 2000Mb will work just fine with their servers. The only reason to use a small part size is if you want to transfer your backup archive to remote storage (e.g. Amazon S3, Dropbox etc)

If the backup still fails please send me the new 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!

Thursday, 12 June 2014 11:53 CDT

GJSchaller

Thank you, Nick, you are the best! :-)

I turned off the conflicting Cache options (both, to be safe), and am running a cPanel backup now. It seems to be working this time - it's passing the point at which it failed last time.

I know I have plenty of room, that should not be an issue (easily 10+ GB still... I set the site up with plenty of extra space specifically for this reason).

I am backing up to a remote site - an FTP Server (ReadyNAS) at my home. Of course, it just told me that there's a file system error during a routine check, so that's currently backing up and repairing itself at the moment, too. When it rains, it pours....

I'll keep you updated on the Akeeba error, but here's hoping it's resolved with the conflicting cache issue.

Thursday, 12 June 2014 13:23 CDT

GJSchaller

OK, all is back up and running again. cPanel backup completed normally. But Akeeba is still giving the same error. New log attached.

Thursday, 12 June 2014 13:23 CDT

GJSchaller

Friday, 13 June 2014 06:30 CDT

nicholas

OK, let's see.

It's not permissions as do get quite a few SQL files put in the archive. It's probably not a corrupt table, SQL query limit or maximum part size as the backup proceeds to different row counts of the table. It's not the number of requests made (19 vs 36 in each backup). It's not the idle time between steps, we eliminated it. It's not the maximum time per step, it's different with each backup. It's not a CPU usage limit since the time to get to the error is anywhere between 1:14 and 3:23. Let alone that you're on a good host which doesn't impose this kind of stupid limits. I am now having a very serious WTF moment.

Can you please try excluding Kunena's messages table and let me know if the backup works? If not, please send me the new log file. I have some suspicions...

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!

Friday, 13 June 2014 07:30 CDT

GJSchaller

I'm honored (?) I came up with such a humdinger!

Kunena tables excluded, still failed. Log is attached.

Let me know if you'd like a login on my site, and I can arrange for a closer look for you.

Friday, 13 June 2014 08:17 CDT

nicholas

Actually we got much further. Now try disabling the upload of parts immediately in the post-processing engine configuration and give it another try. The backup should complete. If not, you know what you have to do :)

I have the increasing suspicion that the backup is terminated due to excessive resource usage triggering a script kill by your host. Could you tell me which SiteGround plan you're using on 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!

Friday, 13 June 2014 08:43 CDT

GJSchaller

Cloud 4 account + General Booster

No changes to the account itself have been made since the last good backup (on the 10th, a few days ago). I did notice that PHP had been updated to 5.4.28 from 5.4.26 recently, which may be related?

Backup failed again - log attached.

Friday, 13 June 2014 10:24 CDT

nicholas

All right, now I am sure. Your host is killing the backup, most likely due to the high CPU/memory/MySQL usage during the backup process. You'll need to talk to them.

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!

Friday, 13 June 2014 10:28 CDT

GJSchaller

It's possible - the site is pretty darn big, although it's backed up before this without issue. I suspect the update to PHP 5.4.28 may have been the change that instigated this.

SG is currently performing a cPanel update on my host server - once it's done, I'll try backing up again to see if this is still an issue, and if it is, I'll open a ticket with them and reference this discussion here.

Sunday, 15 June 2014 18:59 CDT

GJSchaller

Bah.

Hello,

Thank you for your patience!

We have investigated your issue further, but I am afraid that we were not able to fix the web based backup creation. I guess it needs too much resources and we have already raised the resources to the optimal for your server.

What I would suggest is to continue using the cron job based backup generation to properly create the backups of your website via the Akeeba backup service. To avoid any issues with the backup via cron job, make sure to use the following command:

(URL Removed by Geoff)

any other command might fail.

Best Regards,

Kiril I.

Technical Support Supervisor

Edited by GJSchaller on 2014-06-15 18:59 CDT

Monday, 16 June 2014 03:07 CDT

nicholas

All right, then the problem is the resource usage on the shared hosting account (that's why I asked you which hosting package you have signed up for). We can try a few workarounds, but it may not work. Large sites on shared hosting are always an issue: you need a lot of CPU time to back up everything and the shared host cannot provide them without screwing the other clients on the same server. The best solution is to go to a larger (and more expensive) package which gives you more resources.

However, let's try this in Akeeba Backup's Configuration page:
- Minimum execution time: 10 seconds
- Maximum execution time: 3 seconds
- Execution time bias: 50%

This will cause Akeeba Backup to run its backup for 1.5 to 3 seconds, then take a rest of 7 to 8.5 seconds. This will reduce the average resource usage over time by 70-85% with the downside of having the backup take 3-4 times longer.

Moreover, I'd say that you can kiss transferring backups off-site goodbye. This is the kind of operations which cannot be split into smaller steps. You either transfer a file or not. If SG is also monitoring outbound bandwidth per user account (I bet they do) they might kill off the backup process when it's uploading the files to remote storage. The proof in the pudding is in eating it, so there's only one way for us to find out: let's try taking a backup with these settings.

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!

Monday, 16 June 2014 07:45 CDT

GJSchaller

The odd thing is, the other 5 Joomla sites on this server don't have this issue, just this one.

I'm trying now without the option to FTP it off-site checked. It'll stink that I need to do it manually, but it will also mean it's one file, and not 300+ any more.

Monday, 16 June 2014 09:04 CDT

nicholas

Well, not all sites have the same amount of database data and files. Smaller sites back up just fine on shared hosts with limited resources.

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!

Thursday, 10 July 2014 09:56 CDT

GJSchaller

An update on this - SiteGround was not able to resolve this.

I used an older, successful backup, and created a test site, for purposes of upgrading to Joomla 3.3 (the current site is still 2.5). On a hunch, the 3.3 test site backed up fine.

It may be that 3.3 is more efficient than 2.5, or it may be that the load on a non-live site was less, and allowed it to run. In either case, I can make a backup the cPanel way, and then upgrade to 3.3, which hopefully will allow Akeeba Backup to begin regular backups again.

Thursday, 10 July 2014 12:19 CDT

nicholas

I think you are spot on. Joomla! 3.3 is indeed FAR more efficient than 2.5, but that's not the deciding factor. Apparently the site is on a less stressed out server, meaning that the backup is faster, more efficient and less prone to being killed by the host.

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!

Thursday, 10 July 2014 12:22 CDT

GJSchaller

It's the same Clould4 server, just a different cPanel account. It may just be load, since there aren't a ton of users on my test site. ;-)

Thursday, 10 July 2014 13:41 CDT

nicholas

Yes, it should be it. This cPanel user uses minimal resources the way you are describing this test 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!

Friday, 18 July 2014 10:01 CDT

GJSchaller

As a follow up to this, this site was moved to a new Cloud4 account with less load on it, and also CloudFlare was enabled, which also helped reduce load. It's backing up fine, now.

This issue can be closed - thank you for the help!

Friday, 18 July 2014 10:56 CDT

nicholas

You're welcome!

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