Regarding the older backups, the Manage Backups page should have a button in their rightmost column labeled Transfer to S3. This is what happens when the upload fails. However, given that you didn't meet the minimum requirements for the upload code to work it's possible that a remote storage location was never created which would mean that the button doesn't appear. Frankly, this is a scenario I haven't tested in a very long time.
Regarding configuration. You cannot have it mark a backup that failed to upload as outright failed. A backup record is marked as failed when we know we never finished creating the backup archive. This would be a broken backup which can't be restored. Therefore, backup records marked as failed have their backup archives deleted immediately. You definitely don't want that when your perfectly good backup archive failed to upload because, for example, you mistyped the secret key, network conditions didn't let the transfer go through or Amazon S3 experienced an issue on its end. You just want to know this happened so you can retry uploading.
The best way to be notified about the status of your backups upload is to use the Pushbullet notifications integration, see https://www.akeeba.com/documentation/akeeba-backup-documentation/editing-components-parameters.html at the very bottom.
Another way is to have Akeeba Backup send you emails when a backup completes. On the same documentation page look for "Email body". Adding the [REMOTESTATUS] variable will communicate whether the upload worked. If not, you get the message "Post-processing (upload to remote storage) has FAILED". This allows you to create a mail filter in your email client to mark this email as high priority and have the successful backup emails archived immediately.
I use the push notifications.
We also use the Check Failed feature, see https://www.akeeba.com/documentation/akeeba-backup-documentation/checking-for-failed-backups-automatically.html This tells us which backups failed to complete, not just failed to upload. These are the backups which were killed for external reasons before they finished creating the backup archive. We get these very rarely but it's good to know. That's how we discovered, for example, that when our previous host moved us to a new server they forgot to set the CPU usage limits for our account, therefore not giving the CRON jobs enough time to complete the backups.
Finally, if you are using CRON jobs, you can have the output of the CRON job emailed to you. The sender and subject are host and site specific, controlled by your CRON daemon. The message is the output of the CRON script. If it has "finished successfully" in it the backup archive has been created. If it has "warnings" in it there are issues with the backup, one of which could be a failed upload. These known facts allow you to create mail rules either on your mail client or at the mail server level to control which of these emails you want to see. Since I only have a handful of sites and too many many clients across a lot of devices (desktop, laptop, phone, tablet) I just receive all of these emails without filtering and check them every morning to make sure everything is fine.
Between a push notification, the check failed email and receiving the CRON job emails I can definitely tell if something is amiss. That's paranoia level. You just need either of a. the push notifications; b. the email messages (email on backup and the Check Failed one) or c. the CRON job emails. Either of them is enough to help you understand if your backups ran at all, if they ran to completion and if they uploaded to S3.
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!
