Support

Akeeba Backup for Joomla!

#30912 Akeeba doesn't delete backup based on "quota configuration"

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

Latest post by on Sunday, 24 March 2019 18:17 CDT

spot86
Hi Dear,

I have the same problem described here: https://www.akeebabackup.com/support/akeeba-backup-3x/Ticket/30526-strange-behaviour-of-remote-backup.html

I have the settings sintetically represented here:

Activate quota on remote file storage: YES
Activate quota based on time: YES
Max time: Custom - 7.00 - Days
Do not delete backup in this day: 0.00 day (I want to delete all old backup - Is it right to set 0 here?)
Obsolete record to maintain: 10.00 Items
Activate quota based on size: NO
--
Activate quota based on counting: NO
--

But: in the remote folder (Dropbox) I see all the backups, even backups older than 7 days.

Moreover, some backup are still stored in backup folder on local server.

Is there something wrong with my settings in Akeeba Configuration?

Very thanks

nicholas
Akeeba Staff
Manager
Akeeba Backup will only delete the backup archives it knows about. This means that it will look in your site's database for other non-obsolete backup records taken with the same backup profile. Any backup files from that set of records matching your quota criteria will be deleted.

There are very good reasons we are not blindly looking into Dropbox or whatever remote storage service you might be using.

For starters, looking into the remote storage is orders of magnitude slower. Looking into the database takes less than 0.1 seconds. Looking into the remote storage takes anywhere from 2 to 50 seconds. This is the difference between running to completion and having the backup process killed because of a timeout error.

Moreover, you may have multiple sites or backup profiles send similar-named backups into the same remote storage folder. If we looked into the remote storage we'd be deleting other backups we shouldn't be touching. Not to mention that you might store your backups inside a folder with unrelated files or folders. You wouldn't want us to delete everything in your Dropbox by accident, right?

So based on your settings only backups taken on the same site, with the same backup profile, which still appear in your Akeeba Backup "Manage Backups" page will be removed from Dropbox automatically.

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!

spot86
Hi Nicholas
I solved this issue thank for your indication.

It remains unresolved this: https://www.akeebabackup.com/support/akeeba-backup-3x/Ticket/30526-strange-behaviour-of-remote-backup.html

(in particular, some backup are still stored in backup folder on local server.)

The hosting service says is "all right".
Have you any other idea to what can cause the problem?

nicholas
Akeeba Staff
Manager
In the interest of keeping things simpler for you and us, please file a new private ticket about the remaining issue from ticket 30526 and give us connection information to your site (URL, Super User login and SFTP or FTP connection information). Either me or Davide will connect to your site, create a new backup profile that generates a new backup profile and see what's going on.

My guesstimation of the root cause is that either the generated backup archive has the wrong permissions (e.g. the host applies a umask which makes the files undeletable) or the server is slow in releasing the file lock. Right now, all we know is that this is not a bug we can reproduce otherwhere. We use remote storage for all of our own sites' backups and I can tell you for sure that uploaded files are removed. It's something server specific. What exactly? Well, we can't really know without access to the site.

Thank you very much for your patience and for helping us help you!

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!

spot86
Very thanks to you!
I've done what you suggest, via private ticket. ;)

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: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

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!