Support

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: My auto backup worked consistently and the chron job would send over an email indicating successful backups. As part of their upgrade, my hosting provider moved me to a new server. I still get emails, however the auto backups have failed and backups can only be done manually.

Please advise.

I ran Alice Troubleshooter and found the following. Not 100% certain where to make the changes or how to fix

There is already an issue with the backup engine saving its state. Please fix it before continuing.

Please try setting min execution time to 1, max execution time to 10 seconds (or if the PHP timeout is less than 10 seconds, use 75% of the PHP timeout), runtime bias 75%

A post-processing engine is found, but no part size is set; this could lead to timeout issues

Set a part size inside backup profile configuration.

Please zip and post the backup log here. That contains information that will help to figure out what is happening.

Thank you for the log, but this is from a successful back end backup. I need the log from the failed CRON backup to analyze the problem.

My bad Dale, I was waiting for the BU to kick off, which should be anytime now...it didn't so I grabbed a previously failed log. Pls see most recent upload. Thanks

The log is not attached, please try again.

If you can't get it to upload, just throw it on a file service like Google Drive, Dropbox, etc. and give me the link. I'll go get it.

First problem, you're using the wrong version of PHP. If you look at the beginning of your CRON command line, it calls PHP, then passes a number of arguments to PHP. The PHP you're calling on that path is the CGI-FCGI version, you need the CLI version. The path to PHP-CLI varies from one host to another, so I can't tell you the correct path. You might find it in your host's FAQ page, it is something that comes up frequently. You may have to contact support and ask them.

Having PHP-CLI will speed up your backup and ease some timeout problems, but I don't think it will save us in this case. The backup stops at 2 minutes elapsed time. When the job stops on a nice even number like that, it usually means that your host killed the CRON job. This is not at all unusual. They do that to make sure you're not eating up server resources with a run away CRON job. Sometimes the host will extend the time limit, sometimes we have to use a third party CRON system to trigger the job.

Let's get the PHP issue fixed first and see if that speeds the backup job up enough to avoid the CRON job time limit. If it doesn't, then we'll talk about Plan B.

Hey man, looks like plan b: From my hosting provided "Thank you for being on hold, I have checked with the specialists , The upgraded version of the server does not support cgi-cli
The new version of the account supports only cgi-fcgi
So the script must be changed according to the version, Or you will need to to go for VPS servers "

Hey Dale, I am running Joomla v 3.9.14 on php 7.0. Whenever I try to upgrade to php 7.1 or 7.2 I get fatal errors on the website. The error reporting is set to maximum on the server settings of the Joomla global configuration tab. There are some component errors which I am unable to fix, since I have no clue how to do php scripting.

I am looking at porting my Joomla site over to wordpress as I understand that wordpress does not use php scripting. My concern is that if I stay on Joomla, and I do the fixes (maybe have a friend do it) on the php 7.0 n+1 upgrade, I may be forced to re-do it again on future php upgrades.

I suspect that Akeeba is CMS platform agnostic, but it also appears that I also cannot run akeeba against a "php /..cgi-fcgi configured server, unless we look at plan b..

Thanks

Hi, sharing info received back from my hosting provider:

I checked the cronjobs set in your hosting account and following are some observations that I found:
Cron Jobs are set to run once per day which is (0,0,*,*,*).
The path specified in the commands are correct. It is /home1/domain/public_html/
The PHP version on the .htaccess is set to 7.0
I executed the command manually from the SSH and found no errors with the first cronjob set with command php /home1/domain/public_html/emailreminder.php.
However, the 2nd cronjob command displayed an error when executed. I have included the output of the command in the link below:
https://paste.yyyyyyy.com/p/xxxxxxxxxx/

The output has an error specified which says: Failed configuration check Q001: Output directory unwritable. I could not find the output directory in the script cli/akeeba-backup.php. I tried executing the same command after setting the permissions of files and directories to default. However, could not resolve the error.

I would suggest you to check the script and the output directory permissions. Also, please check if the scripts are compatible with the PHP version 7.0 set in the .htaccess. Any permission codes in the .htaccess file can also cause these type of errors. Please feel free to reply to this email if you need any assistance or any information.

First, there is no such thing as cgi-cli, so I wouldn't expect your host to support it. It's possible that we had a communication error. We need the command line version of PHP, usually referred to as PHP-CLI. The cgi-fcgi version won't do. The PHP version is not the root problem. It might speed up your backup enough to work under the CRON time limit, but as your site grows, this problem will haunt us again.

Generally you can't fix errors triggered by a new version of PHP. The extension author needs to do that. For example, there was a report of an error in Akeeba Backup this morning under PHP 7.4. Nicholas replied that it was fixed in version 7.0 1 last week. So look for updates to your extensions that are throwing errors, don't try to fix them yourself. If the extension is no longer maintained, you need to look for alternatives anyway.

The "Output Directory" is normally /administrator/components/akeeba_backup/backups, but it can be changed in the backup Configuration screen. I suspect that this is a red herring. The backup would have thrown an error almost immediately if it couldn't write to the output folder. I think your host killed the CRON job after 2 minutes and we're getting a misleading error.

Plan B is not so bad. Any computer that is powered on at the time you want your backup to run can trigger the backup. Windows computers can use a Scheduled Task, Linux computers run CRON as a native service. Even a Raspberry Pi can trigger it. Using a commercial CRON service is easy and the expense is pennies per backup.

GM Dale, re "First, there is no such thing as cgi-cli, so I wouldn't expect your host to support it. It's possible that we had a communication error." ..no worries...it was a typo on my part.

Re "Generally you can't fix errors triggered by a new version of PHP"..correct, when I mentioned getting a friend to fix, I did not mean writing code to correct. I meant going through the errors and either reaching out to the code author and or come up with alternatives. I did a bit of research since writing and am beginning to wrap my head around the challenges and possible fixes...no my area of expertise to initially took the easiest route.. :-) have a friend fix. Yup..solid advise re looking for alternatives.

Using a commercial CRON service is easy and the expense is pennies per backup...Ok got it...

Help me understand something though...when I kick off a manual backup, it runs to completion...but automated backups fail for the reason previously stated...why does the manual complete?

Thank you.

The time limit we're talking about is not the normal PHP timeout value. Akeeba Backup is designed to break the backup job into small chunks specifically to avoid the PHP timeout. We could adjust the timing settings in the Configuration if this was the problem.

The time limit we're running into is the server level ulimit setting. This is killing your CRON job after two minutes. When the CRON job is killed, the backup dies with it. Since your manual backup does not use CRON, this limit is not applicable.

Apologies in advance for being a pain..with commercial "CHRON" services will the server level ulimit not kill those jobs as well...

Thank you.

You're not a pain at all. The way WebCron works is that during the setup of the CRON job you specify how long the job should run. You pay for that amount of time. It costs .25 euros for a 10 minute job, shorter jobs are cheaper. If your job runs over the time limit, it will terminate, but you have control over the limit.

Ok..I see...got it...I have some decision to make.

Thanks

Please let me know if I can help.

Hi Dale, you may close the ticket, hmmm...I guess I can close it. With the current hosting provider, I will need a VPS or Dedicated server to run the php-cli chron job.

You do not need the php-cli version of PHP for a front end backup. That would be the type of backup that a third party CRON service would perform.

I apologize for reopening the ticket but I wanted to make sure that we were clear on that point. We can live without php-cli.

no worries re opening the ticket. I cleaned up a bunch of files from the server 2 days ago...and the backup Gods must be smiling down on us...I received an email "successful backup"..I checked the cPanel of Akeeba ===> manage backups...and the last backup was green...

Thanks for the assist...great dialogue