Support

Hello Mark,

No, there is no such feature. This is a safety measure. Deleting a backup automatically without keeping a copy of it anywhere would end up in some people losing their sites. Typical scenario: user has an e-commerce site with hundreds of daily transactions. He sets up Akeeba Backup with S3 transfer and schedules the backup. At some point he cancels the old credentials and creates new ones, but forgets to update Akeeba Backup. He doesn't read the emails sent by his server's CRON daemon and is oblivious to the fact that his backups do not get transferred to S3. A week later his site crashes, three hours after the last backup was taken. Here are the two alternative scenarios:

1. If the backups are not removed automatically (how it is now): After the initial panic of not seeing any backups in his S3 folder the user looks in the backup output directory. The backups are there and he can restore his site, losing just 3 hours of transactions. This is a recoverable situation and his business survives.

2. If the backups are removed even when the transfer fails (what you ask for): After the initial panic of not seeing any backups in his S3 folder the user realises that the last backup he has is from a week ago. Having lost hundreds to thousands of transactions his business enters a death spiral and fails.

The only responsible thing for a developer to do is to protect the users from themselves as much as possible. That's why the automatic deletion takes place only after a successful transfer.

A good developer also allows the careful user to easily recover from an unexpected error condition. This is what we've done with the ability of Akeeba Backup to re-transfer backups which didn't complete their transfer to S3 or another remote storage service. Just go to Akeeba Backup, Administer Backup Files and click on the transfer link found in the right hand column. After the transfer is complete you can check the row and click on "Delete Files" (not just "Delete").

the first one probably as an add-on script, rather than as a tick box option, that way you would have to consciously do this, rather than accidentally do it.

Then you don't need me to do that, you just need a CRON job and basic Linux knowledge :) Assuming that your backup files are located in /home/mysite/administrator/components/com_akeeba/backup you'd need to run this every day, a few hours after your automated backup is scheduled to run:

rm -f /home/mysite/administrator/components/com_akeeba/backup/*.j*

As far as I can tell, the failures are just due to internet connections being slow at the time, what about having an option that you could schedule another cron job which runs a couple of hours after the backup (or runs every hour for 6 hours) and just checks any transfer failures and retries, if the retry is successful, it then deletes the local backup.

Um, not really possible due to the way the backup engine is structured. You can't have a backup run check the status of another backup right now. I follow a different approach for my own sites.

By default, the CRON daemon sends an email with the output of the script. If the transfer fails it prints out a very large WARNING block at the end of the output. Just create mail filter rules to leave the emails with the WARNING to your inbox and the emails without the WARNING to your trash. When you see an email with a WARNING you have to log in to your site and perform a manual transfer.