Support

Akeeba Backup for Joomla!

#11472 Kettenrad :: Attempting to load from database (cli)

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 nicholas on Friday, 09 March 2012 02:58 CST

Wednesday, 07 March 2012 16:03 CST

BWakeeba
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: 1.5.25
PHP version: 5.2.17
MySQL version: 5.0.92
Host: (godaddy.com)
Akeeba Backup version: (3.4.1)

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: I can run my backup from the backend to amazon s3 without a problem. However, using native cron or alt cron, I hot this problem:

[120307 14:41:29] Kettenrad :: Attempting to load from database (cli)
[120307 14:41:29] -- Stored Akeeba Factory (cli) not found - hard reset

It's not always at the same point in the backup process, but always the same "hard reset".

Any suggestions of where to look? Thanks.

Thursday, 08 March 2012 01:09 CST

nicholas
I really need you to ZIP and attach the entire log file. The last lines mean nothing. They are written when Akeeba Backup's Control Panel loads. At this stage, Akeeba Backup looks for stalled backups, trying to load the serialised factory (the "memory" file created during backup). In the process, it writes these log lines. A hard reset of the factory at this stage is perfectly normal.

My educated guess is that the root cause of any issue you might have is that your backup takes more than 120 seconds. GoDaddy limits the duration of CRON jobs to 120 seconds. You can try asking their support to increase that limit for you. But before you do, please do ZIP and attach the entire log file. I want to be sure that this is indeed 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!

Thursday, 08 March 2012 13:26 CST

BWakeeba
Attached is my entire log file. Thanks.

Friday, 09 March 2012 02:58 CST

nicholas
Yes, my hunch was correct; GoDaddy terminated the CRON job. You can either ask them to raise the CRON timeout limit. If the say it's impossible or ask you an arm and a leg to do that, you can consider using our front-end backup with webcron.org. Scheduling a year's worth of backups costs less than 2 USD, which is dirt cheap - and ultra reliable too. Information about webcron.org setp and front-end backups can be found in our documentation.

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 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!