Support

Akeeba Backup for Joomla!

#36350 Backup fails with no alert

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

blacknell

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:

Backups are completing as success but recently they post processing has not been completing. I have an S3 upload configured and working fine. Recently, though our provider had a problem on their end so the upload has not been occurring since beginning of December.

I only just noticed it.

However, I am running the cron job to check failed backups and nothing is being reported.

/usr/bin/php /var/www/www.nomadsailing.co.uk/cli/akeeba-check-failed.php --profile=1
Akeeba Backup Check failed backups CLI 8.0.12 (2021-10-26)
Copyright (c) 2006-2022 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 PHP 7.4.25 (cli)

Checking for failed backups
No need to run: no failed backups or notifications were already sent.

It's worth pointing out that the button to finish the post process is there and different to when it succeeded/

WARNING |20220103 03:00:34|Akeeba\Engine\Postproc\Connector\S3v4\Connector::startMultipart(): [500] InvalidAccessKeyId:The AWS Access Key Id you provided does not exist in our records. \n \n Debug info: \n SimpleXMLElement Object \n ( \n [Code] => InvalidAccessKeyId \n [Message] => The AWS Access Key Id you provided does not exist in our records. \n [AWSAccessKeyId] => 009fc991b2c27552ae9d \n [RequestId] => e5625c88-ffe5-1fff-b80f-0cc47ad3f148 \n [HostId] => bde0729579de457cb50d41e91a04137b \n ) \n
DEBUG |20220103 03:00:34|[Akeeba\Engine\Postproc\Connector\S3v4\Exception\CannotPutFile] <root>administrator/components/com_akeeba/BackupEngine/Postproc/Connector/S3v4/Connector.php(693) – #0 ‹Akeeba\Engine\Postproc\Connector\S3v4\Connector::startMultipart(): [500] InvalidAccessKeyId:The AWS Access Key Id you provided does not exist in our records. \n \n Debug info: \n SimpleXMLElement Object \n ( \n [Code] => InvalidAccessKeyId \n [Message] => The AWS Access Key Id you provided does not exist in our records. \n [AWSAccessKeyId] => 009fc991b2c27552ae9d \n [RequestId] => e5625c88-ffe5-1fff-b80f-0cc47ad3f148 \n [HostId] => bde0729579de457cb50d41e91a04137b \n ) \n ›
DEBUG |20220103 03:00:34|Not removing the non-processed file <root>administrator/components/com_akeeba/backup/site-www.nomadsailing.co.uk-20220103-030001-zHBvR7RIuVnBRc-U.jpa
WARNING |20220103 03:00:34|Post-processing interrupted -- no more files will be transferred

But my view is that if the post process fails, then the job has failed.

We had a recent disaster recovery situation where all our jpa backups were lost because our hosting provider cancelled our account and even though we were moving our jpa's to a completely different part of their service we also lost the jpa's

So the fact jpa's are still on the joomla server waiting for manual upload doesn't help if I lose the server

I believe the akeeba-check-failed.php script should send the alert if the transfer failed. 

The job is configured to back up joomla and transfer the JPA and it didn't/

nicholas
Akeeba Staff
Manager

I have explained this many times over the year.

If the upload fails your backup has not failed. Your backup is taken and it's valid. You can restore it. You have a working backup.

That's why upload failures are warnings, not errors. Errors stop the backup process, delete all files and mark the record as failed. Warnings mean that the backup did finish, it is valid but you need to take a look.

If we treated upload failures as errors you'd completely lose that backup. There are many more cases where this is a much bigger problem than having the backup archives sitting on your server until you rectify the issue and use the interface to upload them to remote storage.

The correct approach is to have the results of the backups emailed to you and use mail filters to flag backups with warnings. You can archive the successful backups — even though I prefer not doing that so I know which backups actually run after having been burned once with a CRON job that stopped working.

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!

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.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.