Support

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 agency has recently decided to use a daily scheduled automated native CRON job to back up our main website. My unit does not have access to the CLI PHP, so we worked with the Server Unit to set up the job.

It has run on 2 nights so far, and both nights generated 59 failures according to the Manage Backups screen, and then a single backup with an "OK" status.

The first night the job was scheduled to run at 6pm. The successful backup finally started at 6:59:06 pm. The second night, I had the time adjusted to 7pm, and that successful backup finally started at 7:59:04 pm. My guess that the CPU may have been overtasked with other jobs at 6pm does not seem to be the solution.

The only log file from this scheduled does not have any errors that I can find - only the information on the last successful backup. That file is 11.3Mb so it will not attache. I am working on splitting the file so I can send it later.

Do you have any idea why there are so many fails?

The Angie report had the following information as "error"

Backup engine state saving issues
Error
Backup engine died without its state having been saved. The engine was stepped 27170 times, saved 27171 times
Please check if you have enough disk space; if your part size is more than 5Mb (or it's 0) please try part sizes of 20, 10, 5 and 2Mb.
If you still get this error, change time settings inside Akeeba Backup; try minimum execution time 1, maximum 7 and runtime bias 50. If this doesn't work try minimum 5, maximum 3 (yes, max is less than min) and bias 50.

Large files issues
Error
The following files are too big and can cause backup issues:
File: /images/docs/HESC_Correspondence_System_Overview_w_audio.ppsx 13.72 Mb
File: /images/docs/HESC_Correspondence_System_Overview_w_audio_121514.pptx 13.72 Mb
Please try excluding these files using the Files and Directories Exclusion feature or delete them if you are sure you don't need them on your site.

I have excluded the 2 large files from tonight's backup to see if that changes anything. I also have hopes of trying to catch one of the error log files as well.

1. Please post a copy of the CRON job setup. Some of our automated backups require the PHP-CLI environment. If PHP-CLI is not available, we have other options. Your host may already be using them, but I need the CRON info to be sure.
2. Something isn't right with your CRON job. Your version of Akeeba Backup will detect certain fatal errors, such as a timeout, and restart the backup. But it does that within the CRON job, it does not start another job. You should not see 59 failed jobs in Manage Backups. The copy of the CRON setup will help with this too.
3. Back end backups keep multiple copies of the log file. The log files are matched with the job number on the Manage Backups screen. For technical reasons, only the most recent CRON backup log is kept. That log would not have a job number associated with it.

It may be helpful to start your CRON job on an odd minute, say 6:07, to allow the group that started at 6:00 to finish before your's starts.

Another 2 CRON runs (Thursday and Friday), another 59 failures each then a successful run.

Here is what our Server admin gave me for the CRON job:

* 19 * * 1-5 /usr/bin/php /var/www/html/hescnygov/cli/akeeba-backup.php
This is a very standard run mon-Friday cron job, there is nothing to make ir rerun or anything of that sort. php-cli is installed.

The ALICE found this:
Additional database - Wrong access details
Warning
Could not detect the used profile, test skipped
Additional database - Joomla database inclusion
Warning
Could not detect the used profile, test skipped

The log file for the Friday night run that kicked off at 19:00 was only 318 bytes, so I have attached it to this response.

Hopefully this file will attach...

And I don't know if it's relevant, but the website is large and the .jpa file is over 272 Mb

* 19 * * 1-5 /usr/bin/php /var/www/html/hescnygov/cli/akeeba-backup.php

Let's change that to

6 19 * * 1-5 /usr/bin/php /var/www/html/hescnygov/cli/akeeba-backup.php

so that it runs at 19:06. I think the way it is set up, we're telling it to run every minute of hour 19. That ties with what we're seeing in the Manage Backups screen.

It looks like you have an additional database defined to be backed up, but the login credentials are not right. I think it is your main database, so you can just delete that extra database. The main database is always backed up in a full site backup.

There is some indication that it can't read the profile, but I think that is a red herring. Let's see what changing the CRON job does with that message.

Our Server support has made the changes to the CRON job, and I will report tomorrow a.m. on what it generated.

As for the database warnings - I checked the profile and there is no extra database configured for the profile.

However, we are currently in the midst of moving or redirecting all of our servers from a Friendly-name.server.com:3306 naming convention to an IP based connection (eg. 999.999.999.999:3306) reference. We have not yet updated the configuration.php file to have the IP connection reference.

I am checking with our network and server people to see if that server reference for the host DB server is ready to be changed for this production website yet. That may clear up those 2 warnings.

If I'm right about the CRON job running every minute, it is possible that the backup job just gets confused. We'll see what it tells us tomorrow.

SUCCESS! You were correct that by adjusting the CRON to start at a specific minute rather than using an * worked. It seems it was interpreting the asterisk as a wild-card and restarting the job every minute.

So last night only produced one job which successfully ended, and the file was used to re-create our production website on our development server (because an untested backup is no backup at all, a lesson we learned the hard way, just once.)

I will be seeing if adjusting the configuration.php file from the friendly-name.server.com:port to and IP address:port gets rid of the ALICE warnings, but it doesn't affect the end product of the CRON job.

I think this issue can be closed. Thank you for all of your help.

You're welcome! I'm glad it's working now.

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.