Support

Akeeba Backup for Joomla!

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

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.
Tuesday, 12 February 2019 02:32 CST
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
Custom Fields
Joomla! version (in x.y.z format) 3.9.2
PHP version (in x.y.z format) 7.0.33
Akeeba Backup version (x.y.z format) 6.3.3.
spot86
Tuesday, 12 February 2019 04:34 CST
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



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
Tuesday, 19 February 2019 05:43 CST
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?
spot86
Thursday, 21 February 2019 03:25 CST
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



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
Thursday, 21 February 2019 15:22 CST
Very thanks to you!
I've done what you suggest, via private ticket. ;)
spot86
Sunday, 24 March 2019 18:17 CDT
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.
system
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

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!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.