Akeeba Backup for Joomla!

Thursday, 23 February 2012 03:54 CST

domini

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: Joomla! 1.5.25 Stable [ senu takaa ama mamni ] 14-November-2011 18:00 GMT
PHP version: 5.2.14-0.dotdeb.0
MySQL version: 5.0.51a-24+lenny5
Webserver version: Apache/2.2.9 (Debian) mod_perl/2.0.4 Perl/v5.10.0
Akeeba Backup version: Akeeba Backup Professional 3.3.13 (2012-01-29)

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:
Dear Akeeba,
about 1 month ago, we have upgraded Akeeka to version 3.3.13. Since previous update, that we did 2 month ago, akeeka backup become very slow (from 9 to 20 hours) to save backup on external ftp.
No change configuration on webserver/database server, no change configuration on ftp server.

Backup file are about 250MB. I tried to upload it from webserver to ftpserver manually and it took me 10 minutes.

Are there parameters that have changed in new version or that must be set?

Can you help me?

Thank you for you support!

Best Regards

ps: in attach the akeeba log file of the last backup.

Thursday, 23 February 2012 04:01 CST

nicholas

Akeeba Backup does not control or throttle the speed of the upload. It all depends on the link speed between the two servers, the one holding your site and the one where you store your backup to. Moreover, please take into account that when you are uploading a backup file, the backup is already taken and you are merely transferring a file. What takes a very long time in your case is taking the backup, not transferring it.

The backup log file tells me that you have tweaked several settings in Akeeba Backup's Configuration. You are dumping up to 10 rows per batch, which is too low and backing up large tables with hundreds of thousands of records (like Finder's tables) takes forever to complete. Moreover, you seem to have modified the fine-tuning settings.

You can always try creating a new backup profile to see what the default settings are and reset the settings in your backup profile. This should speed up the backup process.

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, 24 February 2012 09:22 CST

domini

...but the server is the same (no tuning o change), data are the same. We have not made any changes. So we only have just updated Akeeba backup.

In add, I can say you, a fresh installation for test server have the same problem.

Should you require any further information, please contact me.

Thank you

Friday, 24 February 2012 09:43 CST

nicholas

And the code is exactly the same since 3.3.5. Only bug fixes have been made, none of which can affect performance. But I do see something which is not supposed to happen. Take a look at this log excerpt:

INFO    |120223 22:47:30|Continuing dump of #__jxfinder_terms from record #409543
DEBUG   |120223 22:47:31|----- Finished operation 6 ------
INFO    |120223 22:47:31|Continuing dump of #__jxfinder_terms from record #409553
DEBUG   |120223 22:47:32|----- Finished operation 7 ------
INFO    |120223 22:47:32|Continuing dump of #__jxfinder_terms from record #409563
DEBUG   |120223 22:47:33|----- Finished operation 8 ------
INFO    |120223 22:47:33|Continuing dump of #__jxfinder_terms from record #409573

Your database server is DEAD SLOW. It takes one second to return 10 rows (dumping 10 rows to the SQL file takes about 0.01 seconds). How do I know it's a database server performance issue and not a filesystem performance issue? I read the rest of the log file. File backup is lightning fast. There you have it. Your bottleneck is the database.

FYI, Akeeba Backup's performance has improved over time. This site used to take 3 minutes to back up using Akeeba Backup 3.3.0. Now it only takes 2 and a half. The site's size has increased by 20% in the meantime. The backup speed from 3.3.5 up to and including 3.3.13 has not changed at all.

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, 16 March 2012 05:19 CDT

domini

Dear Akeeba,
we checked that you told us about the database and discovered we don't have same time to take 10 rows.

We decide to restore an old machine where akeeba was installed and we found that the parameter "Number of rows per batch" is different. In the old machine is 1000.00 queries instead in the wizard of the current machine is 10.00 queries.
We changed it in the current machine(set to 1000.00 queries) and the result was the backup take 10 minutes instead of 10/20 hours.

Can you give me explanations about it?

Best regards.

Friday, 16 March 2012 05:26 CDT

nicholas

I think I didn't understand your original request. You meant that the backup is slow, not accessing the site? In this case, yes, I can help. The number of queries per batch is never automatically changed. Someone that works for you or with you on that site changed that. The default value is always 1000 rows. You only need to lower that if you have backup issues.

Do you want me to take a look at all of the backup settings and try to optimise the speed of the backup process?

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, 16 March 2012 05:31 CDT

nicholas

Oops, sorry about that last reply. I confused your request with a similar one I had replied to just a few minutes ago. The fact remains that 10 queries per batch is very low and that the wizard doesn't change that value automatically.

Moreover, since I had last replied to your ticket, I also found out that JXFinder creates huge tables which needn't be backed up. All the #__jxfinder_term* tables can be skipped from the backup (use the "Skip Contents" feature); just rebuild Finder's index on the restored site. This will speed up the backup to take just a few minutes instead of hours.

Do you want me to take another look at your backup configuration?

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, 16 March 2012 06:09 CDT

domini

..don't worry for confused request!
Anyway I seen that as default akeeba take 10 queries instead of 1000 queries and no one changed it.
I followed this checks:
I checked database and noticed that jxfinder have any problem. So, before to wrote you, we disable and uninstall component in joomla and checked if there were database tables of jxfinder. Then we checked that the database was empty from jxfinder component, we tryed to make backup and the time was always hours hours hours.

After we checked in old machine and we notice the parameter "Number of rows per batch" is different. But problem is that this paramater is different as default. Are you sure is not an upgrade that caused it?

If you want Can I attach my configuration backup... anyway with 1000queries it only takes 10 minutes... this time is ok for us.

Friday, 16 March 2012 06:20 CDT

nicholas

Yes, the default has always been 1000 queries per batch. 10 is way too low. I'm not sure what happened. Maybe someone tried to speed up the backup or deal with a backup issue (our troubleshooting instructions tell you to try lowering that to 100 or 10), changed it and forgot about it. No worries :)

10 minutes for a backup sounds very reasonable. My own site takes 4 minutes and I am on a blazing fast server. Backup times up to 15 minutes per Gb are within the normal limits.

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, 16 March 2012 11:19 CDT

domini

The man that works with akeeba backup told me:
"Every time I run the wizard (and the wizard is automatically suggested after every upgrade) it change the value from 1000 to 10".

This sounds like that the default parameter is 10 and not 1000.

Anyway, now we are satisfied of 10 minutes.

Friday, 16 March 2012 11:35 CDT

nicholas

This happens when one of the following is true:
- Your server does not report the total available PHP memory
- You have too little (less than 32Mb) of total available PHP memory
- Your server does not report the PHP memory usage correctly or at all
- The average row length of at least one of your tables exceeds 1/1000 of the available RAM

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!

Sunday, 15 April 2012 18:00 CDT

System Task

system

This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support