Support

Akeeba Solo

#26276 Manual backup stops at 50% - no error message

Posted in ‘Akeeba Solo (standalone)’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
Akeeba Solo version
n/a

Latest post by dimple on Monday, 10 October 2016 05:56 CDT

Friday, 07 October 2016 09:37 CDT

dimple
Hi,
I have taken over a Joomla website and added Akeeba like I have done with all my other sites. Never had this problem before. I can back up the database alone, but see that the files are being skipped and the finalising process bar simply stops 1/2 way through on Full Site Backup. No server response for 2 hours. No error message.

I have looked through all the tickets, have tried changing the part size for split archives, all the timing, (yes the odd looking one as well), checked my paths and so on. I have also increased the PHP configurations on the server. I also have plenty of extra space (488MB out of 5 Gb).

Eventually I downloaded the files, exported the database and loaded it all to my test site. Akeeba works perfectly on the cloned site.

Both sites are on Hetzner severs with exactly the same configurations.
I am totally at a loss, and hoping you can help.
Kind regards.

Friday, 07 October 2016 10:50 CDT

dlb
Please check the tmp folder setting in the Joomla! Global Configuration. It should not be pointed to the root of your site. I would expect an error message if that was the problem, but maybe not.


Dale L. Brackin
Support Specialist


us.gifEnglish: 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)

Friday, 07 October 2016 10:58 CDT

dimple
Interesting. I did have that message on the cloned site and reset the the path to:
/usr/www/users/xxx/tmp

I have done this on the real site as well, and it makes no difference. Is there anywhere else the tmp path could have been set? I think the original has been moved around a bit (without Akeeba)

Friday, 07 October 2016 11:48 CDT

dimple
PS. The Joomla configuration.php file shows the same path as above, and the .htaccess file is bog standard. The same path works for all my other sites which work perfectly with Akeeba. So, where else could Akeeba be getting <root> from?

I hope I'm making sense here.

Friday, 07 October 2016 12:07 CDT

dlb
The <root> in the log is just a placeholder. The log does not show the actual root path.

My first thought was your open_basedir restrictions, but if it works on one, it should work on the other. Is there any difference between the two strings?

Please also check the log folder setting in the Joomla! Global Config. If that was wrong, we should see "skipped" in the log and none of the files would be backed up. It shouldn't get stuck.


Dale L. Brackin
Support Specialist


us.gifEnglish: 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)

Friday, 07 October 2016 12:26 CDT

dimple
1. The open_basedir files are exactly the same on both sites. (I tried commenting out '$obd = ini_get('open_basedir');' but that did not work so I set it back to what it was
2. The log folder setting is: /usr/www/users/xxx/logs - same as all my other sites. The error.php file in the log only shows someone trying to access the site (username and password do not match)

Friday, 07 October 2016 12:38 CDT

dlb
Everything is fine, it just doesn't work.

Please download Akeeba Backup from the Downloads page and install it twice, back to back, without doing anything else in between. It is possible that there are missing files from your last upgrade, this trick usually fixes that problem.


Dale L. Brackin
Support Specialist


us.gifEnglish: 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)

Monday, 10 October 2016 01:04 CDT

dimple
I had done that already. Then, on Friday I downloaded the prof. version and tried it twice too, still did not work.

Over the weekend I have done the following:
1. Downloaded the site files, and exported the database.
2. Uploaded the cloned site to my test server - one level up, and Akeeba worked.
3. I took the resulting .jpa file and loaded it to a test folder on the client's server - one level up (using a fresh database). It worked.
4. Moved all the original files into another folder, and loaded the .jpa file to the root folder (public_html) of the client with a fresh database. It failed. I also tried to back up, excluding the folder with the original files. It failed.

So, there must be a problem with something on the root folder of the client. The host techies asked me to ask you about other PHP settings that we don't have access to. We have the following:
PHP Version: 5.6
allow_url_fopen: off
ioncube: off
display_errors: off
memory_limit: 128MB
max_execution_time:10 seconds
max_input_vars:2500 variables
upload_max_filesize / post_max_size: 64Mb

This is very weird... and your help is very much appreciated.

Monday, 10 October 2016 01:28 CDT

nicholas
Hello Bodil and thank you for your continued trust in our products! I am the lead developer of Akeeba Backup and will be taking over this support ticket as it seems to be a bit more technically involved.

The log file tells me that PHP suddenly stopped working when we started scanning the contents of the root directory. I have three possible causes but I need your help in determining which one is plausible.

1. Very old PHP version. We have determined that PHP versions 5.6.0 to 5.6.5 (and possibly up to 5.6.10) crash inexplicably due to some bugs in the PHP internals (the way it handles the generated opcode before executing it). First check the exact PHP version on each server by going to Joomla's administrator backend, System, System Information and click on the PHP Information tab. The exact PHP version is displayed in big, bold type.

If the site where it works has a newer version (see how to read version numbers) than the site where it doesn't work you have hit this exact PHP bug. The only solution is to please ask your host to update to PHP 5.6.26, the latest PHP 5.6 version.

2. Too many files and folders. That's a bit less likely since we have about 100 Mb to store directory information in memory and each file or folder takes up about 2-3Kb. In any case please check how many directory entries (files and folders) you have in your root directory. If it's over about 2000 entries you are hitting a design limitation of the filesystem itself.

Long story cut short, the time for the filesystem itself to list directory contents is exponentially proportional to the number of files. This performance impact is insignificant in the low hundreds of directory entries but becomes measurable when you hit one or two thousand entries. At 8 thousand entries it may take close to half an hour to list the directory contents, especially on a busy filesystem like that on a shared host. Since Apache has a maximum execution limit of about 120 seconds before it kills the child process handling output generation (i.e. PHP) if you have too many directory entries you may end up triggering a hard timeout during the directory scanning phase.

3. Last but not least, we have seen bad hardlinks and symlinks in one other server. When we tried to list them PHP thew a segmentation fault (it crashed, hard). The crazy thing with these links was that the owner and contents appeared to be different when you listed them using a different PHP API (DirectoryIterator and opendir). All you can do is check if you have symlinks on your site's root and, if you do, try removing them and see if that works. If that works just create the symlinks afresh.

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, 10 October 2016 03:59 CDT

dimple
Hi Nicholas,
Thanks you for your very comprehensive reply.
However, the host came back to me at the same time with the fix:
"There was an old/defunct public_html symbolic link inside the public_html directory itself which caused the issue."

The backup works perfectly now. (I've tested it too.)

Kind regards to all.

Monday, 10 October 2016 05:01 CDT

nicholas
A ha! So it was indeed problem #3. To be honest, I thought that was the least likely to happen :D I'm glad it's all fixed now!

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, 10 October 2016 05:56 CDT

dimple
Thank you so much for all your and Dale's help.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!