Support

Akeeba Backup for Joomla!

#27654 Frontend Backup Failing

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
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

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by swissrog on Wednesday, 03 May 2017 03:35 CDT

swissrog
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:

Ever since the update t J! 3.7 my weekly frontend backups are failing. Site is http://cineaulac.ch. Please see the attached bug log (which I can't interpret).

Many thanks!

swissrog
Update: here's the email I get from my hosting provider with further details:

Akeeba Backup CLI 5.3.1 (2017-03-16)
Copyright (c) 2006-2017 Akeeba Ltd / Nicholas K. Dionysopoulos
-------------------------------------------------------------------------------
Akeeba Backup is Free Software, distributed under the terms of the GNU General
Public License version 3 or, at your option, any later version.
This program comes with ABSOLUTELY NO WARRANTY as per sections 15 & 16 of the
license. See http://www.gnu.org/licenses/gpl-3.0.html for details.
-------------------------------------------------------------------------------

You are using Joomla! 3.7.0 on PHP 7.0.17 (cli)

Starting a new backup with the following parameters:
Profile ID 1
Description "Command-line backup"

Current memory usage: 2.1 Mb

Unsetting time limit restrictions.

Site paths determined by this script:
JPATH_BASE : /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch
JPATH_ADMINISTRATOR : /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator



********** ERROR! **********

Call to a member function get() on null

Technical information:

Code: 0
File: /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/libraries/joomla/session/handler/joomla.php
Line: 71

Stack Trace:

#0 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/libraries/joomla/session/session.php(648): JSessionHandlerJoomla->start()
#1 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/libraries/joomla/session/session.php(608): JSession->_start()
#2 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/libraries/joomla/session/session.php(486): JSession->start()
#3 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/libraries/joomla/factory.php(236): JSession->get('user')
#4 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupPlatform/Joomla3x/Platform.php(365): JFactory::getUser()
#5 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Platform.php(272): Akeeba\Engine\Platform\Joomla3x->get_local_timestamp('Ymd')
#6 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Util/FileSystem.php(145): Akeeba\Engine\Platform->__call('get_local_times...', Array)
#7 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Util/FileSystem.php(174): Akeeba\Engine\Util\FileSystem->get_archive_name_variables()
#8 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Core/Domain/Init.php(446): Akeeba\Engine\Util\FileSystem->replace_archive_name_variables('site-[HOST]-[DA...')
#9 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Core/Domain/Init.php(264): Akeeba\Engine\Core\Domain\Init->getArchiveName()
#10 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Base/Part.php(255): Akeeba\Engine\Core\Domain\Init->_run()
#11 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Core/Kettenrad.php(314): Akeeba\Engine\Base\Part->tick()
#12 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/BackupEngine/Base/Part.php(259): Akeeba\Engine\Core\Kettenrad->_run()
#13 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/administrator/components/com_akeeba/Model/Backup.php(217): Akeeba\Engine\Base\Part->tick()
#14 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/cli/akeeba-backup.php(239): Akeeba\Backup\Admin\Model\Backup->startBackup(Array)
#15 /var/www/vhosts/cineaulac.ch/joomla.cineaulac.ch/cli/akeeba-backup.php(428): AkeebaBackupCLI->execute()
#16 {main}

nicholas
Akeeba Staff
Manager
Akeeba Backup CLI 5.3.1 (2017-03-16)


You are NOT using Akeeba Backup 5.3.4, you are using Akeeba Backup 5.3.1. Moreover you are NOT using the front-end backup feature, you are using the CLI CRON script. These are very important differences.

As we have already announced Akeeba Backup 5.3.1 is affected by major Joomla! bugs. We worked around them. Please upgrade to Akeeba Backup 5.3.4 and let your scheduled CLI backup run again. You'll see it works.

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!

swissrog
Sorry, but I AM running Akeeba Backup 5.3.4, as is proven by the attached debug log (btw, the one I sent earlier also says 5.3.4, now?

Here's the text I got back from my hosting provider's admin frontend. Can you help, please?


Akeeba Backup CLI 5.3.4 (2017-04-30)
Copyright (c) 2006-2017 Akeeba Ltd / Nicholas K. Dionysopoulos
-------------------------------------------------------------------------------
Akeeba Backup is Free Software, distributed under the terms of the GNU General
Public License version 3 or, at your option, any later version.
This program comes with ABSOLUTELY NO WARRANTY as per sections 15 & 16 of the
license. See http://www.gnu.org/licenses/gpl-3.0.html for details.
-------------------------------------------------------------------------------

You are using Joomla! 3.7.0 on PHP 7.0.17 (cli)

Starting a new backup with the following parameters:
Profile ID 1
Description "Command-line backup"

Current memory usage: 2.4 Mb

Unsetting time limit restrictions.

Site paths determined by this script:
JPATH_BASE : /var/www/vhosts/cineaulac.ch/httpdocs
JPATH_ADMINISTRATOR : /var/www/vhosts/cineaulac.ch/httpdocs/administrator

Last Tick : 2017-05-02 16:17:53 GMT+0000 (UTC)
Domain : init
Step :
Substep :
Memory used : 6 Mb
Warnings : no warnings issued (good)

Last Tick : 2017-05-02 16:17:53 GMT+0000 (UTC)
Domain : installer
Step :
Substep :
Memory used : 6.03 Mb
Warnings : no warnings issued (good)

Last Tick : 2017-05-02 16:17:53 GMT+0000 (UTC)
Domain : installer
Step :
Substep :
Memory used : 6.03 Mb
Warnings : no warnings issued (good)

Last Tick : 2017-05-02 16:17:53 GMT+0000 (UTC)
Domain : PackDB
Step :
Substep :
Memory used : 6.07 Mb
Warnings : no warnings issued (good)

Last Tick : 2017-05-02 16:17:53 GMT+0000 (UTC)
Domain : PackDB
Step :
Substep :
Memory used : 6.32 Mb
Warnings : no warnings issued (good)

An error has occurred:
Akeeba\Engine\Dump\Base :: Database Error: Could not connect to MySQL

Peak memory usage: 7.01 Mb

nicholas
Akeeba Staff
Manager
That's progress. First of all you are now running Akeeba Backup 5.3.4. If you compare your previous post with this one you will see that you are now past the Joomla! bug which caused the script to fail immediately with a session error. Your backup proceeded, it initialized and then it stopped with a database error.

Still, as I explained above, you are ABSOLUTELY NOT using the frontend backup feature. Please read the documentation, or even what you pasted. You are running the Akeeba Backup CLI (command line interface) script. Your site is running inside a web server, most likely Apache. Your site has a public frontend and an administrator backend. Akeeba Backup does offer two remote backup interfaces from the public frontend. You are using neither. We offer a third way to run backups, outside of the web server, through the command line. This is what you are using. It is ABSOLUTELY CRUCIAL that you understand that difference. Right now, your backups run under a DIFFERENT PHP executable than your web site's public frontend and administrative backend. Please keep that in mind for my next reply.

Moreover, you did not attach the backup log file. You have pasted the output of the CRON script. I need you to ZIP and attach the log file. If you are not sure what this is, please read this page.

There are two possibilities about why your backup is failing. That's why I need the log file, to see what is going on. The possibilities are:

1. You have accidentally set up an extra database to back up, without giving any connection information. If you try to take a backup from your site's backend and it fails then that's the case. It can be fixed by removing the extra, but empty, database definition.

2. Your PHP CLI version is 7.0 but your web server is using an earlier version of PHP. I won't be able to rule that out with the log file. Do check your configuration.php file. If the dbtype is mysql (WITHOUT a trailing i) change it to mysqli (WITH a trailing i) and run the backup again. Long story cut short, PHP 7.0 and later do not support the old, obsolete mysql (WITHOUT trailing i) driver. PHP 5.2 up to and including PHP 7.1 (and everything in between) DO support mysqli (WITH the trailing i).

3. The PHP CLI executable can't connect to your database host. Switching between localhost and 127.0.0.1 does the trick. The reason is rather esoteric but if you want I can explain it to you.

The log file will help me understand if possibility 1 is possible. If it is, 2 & 3 are not and we rule them out. If that's not the case we're left with both 2 &3 so we try both fixes and see what works. I could have you collect more definitive information but, frankly, it's more complicated than making two simple changes in your configuration.php 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!

swissrog
Hi Nicholas & thanks for baring with me ... you're right, of course, that it's a CLI backup, not a frontend backup. That said, I haven't changed anything on the hosting/server side (PHP versions or such) since the upgrade to J! 3.7.

As to your points:

1. I'm attaching what I hope is the correct and zipped log file. As you know the backups have all failed recently, which would explain the small file size.
2. dbtype from configuration.php: "public $dbtype = 'mysqli';", so should be OK, right?
3. where would I need to change the IP for the database host? configuration.php? Is there any risk of interrupting the site (aka "breaking something")?

Thanks for your continued help!

Roger

nicholas
Akeeba Staff
Manager
1. Yes, that's the one!
2. That's OK
3. Yes, that's in the configuration.php file and we do have to change it. Always make a copy of your file before modifying it. This way if something goes wrong you can simply revert to the last known good copy of that file. After taking a copy of the file look for the host line, e.g.:
        public $host = '127.0.0.1';

Try switching between 127.0.0.1 and localhost. One of them should work.

If both fail ask your host to take a look. It's possible that they made a change to the server at around the same time you upgraded Joomla.

If they've made no changes it's possible that you have a failed Joomla! update. Try downloading the update (not installation!) Joomla package, extract it and upload all of its files to your site. Then log in to the backend of the site and go to Extensions, Database and click on the Fix button.

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!

swissrog
Thanks!

I took a copy of the configuration.php (glad I did) and changed the host to the IP you gave me. Immediately, the site was no longer accessible, so I switched back to the original configuration.php. I notice, however, that the host also has a port number listed under the setting;

public $host = 'localhost:3306';

I guess I'll contact the hosting provider and see whether they have any known issues with J! 3.7.

Will keep you posted.

nicholas
Akeeba Staff
Manager
OK, now that makes much more sense. The shorthand localhost:3306 is invalid. "localhost" means "use named pipes or shared memory to communicate with the database server". A port means "use TCP/IP to communicate with the database server". Obviously these cannot happen at the same time.

Try changing that line first to

public $host = 'localhost';

If this doesn't work, change it to

public $host = '127.0.0.1';

If this still doesn't work change it to

public $host = '127.0.0.1:3306';

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!

nicholas
Akeeba Staff
Manager
Also FYI the use of localhost:3306 was constrained to the old, obsolete "mysql" driver, see PHP manual http://php.net/manual/en/function.mysql-connect.php

As you can read there the localhost:3306 was the default setting when using the architecturally incorrect SQL safe mode. It was understood to mean 127.0.0.1:3306. Also, the manual goes on to say that you shouldn't do that:

Whenever you specify "localhost" or "localhost:port" as server, the MySQL client library will override this and try to connect to a local socket (named pipe on Windows). If you want to use TCP/IP, use "127.0.0.1" instead of "localhost".

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!

swissrog
That did it! Removing the 3306 reference enabled the backup and I just kickstarted (no, not with your tool) one. Works like a charm again!

Many thanks for your help and information ... always eager to learn!

Cheers!

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!