Akeeba Backup for Joomla!

Tuesday, 07 July 2020 19:44 CDT

local44-admin

Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

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: We noticed a while ago that automatic backups were not even starting, possibly due to the cron calling an old PHP version. So we updated the cron to use php 7.3. Now the backup starts, but gets about 73% complete and stalls. No relevant error that I can see. Checked with Bluehost and they don't report anything out of the ordinary.

I tried setting the backup settings to Min 1s, Max 10s, Bias 75% -- no change.

Manual backup is working, so I assume we would be able to use the front-end backup if needed. But we previously had this working on this host, so it feels like it oughta work here. Any further suggestions?

Thanks in advance.

Edited by on 2020-08-08 17:45 CDT

Tuesday, 07 July 2020 23:45 CDT

nicholas

Ask your host to check the ulimit -t (CPU time limit) for your hosting account. Based on what I see there's a fair chance it is really low, 60 seconds or less. This means that the Operating System is killing the CRON job which runs the backup before the backup is complete. They would need to increase it to something that's higher than the time it takes for a backup to complete on your site (you can check that in the Manage Backups page).

If that's not the case they need to check if there is something else which could be calling the CRON job process. If there's nothing like that you should try using PHP 7.2 to 7.4 for your CRON job, in case the PHP 7.3 binary has a bug which causes the PHP core itself to crash.

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!

Wednesday, 08 July 2020 12:32 CDT

local44-admin

Appreciate the info. Bluehost says they increased the timeout (I had asked for 10 minutes, as our manual backups complete in 5-7m, but they didn't tell me what they increased it to), but it didn't help.

Rather than endure more back and forth with Bluehost, I switched to the front-end option with WGET and a long secret word. That seems to work, so I'll leave it like that for a few days and monitor.

Thursday, 09 July 2020 01:43 CDT

nicholas

Your observations are consistent with the problem being caused by the host killing the CRON job. Using a frontend backup sidesteps this problem. WGet itself consumes meager amounts of CPU time. Most of its runtime is spent in network wait which doesn't count as CPU time (the CPU is idle for that process). The heavy lifting is performed by the page loads triggered by WGet but these happen in a different web server process each. It's a good alternative in your case.

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!

Saturday, 08 August 2020 17:17 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.

Edited by on 2020-08-08 17:17 CDT

Support