Support

Akeeba Backup for Joomla!

#27325 count quota not deleting oldest file

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 inlico on Tuesday, 14 March 2017 04:37 CDT

inlico
We keep daily automated backups via native Cron script. Yesterday, we transitioned from keeping files on the server to uploading them to Dropbox. With it came some tuning of quotas, namely setting a size quota and enabling remote files quota; 'Delete archive after processing' is now checked; count quota was already set to 5.

Today I can see two jpa files in Dropbox and three in the server, but oddly enough the file disposed of in the server was not the older but the most recent.

Of course this is not a problem for us; the whole arrangement works great and last, useful backups are now elsewhere; but I thought I would drop a line here just in case you were interested to look into the issue.

Running ALICE on five last logs gives:
"The log analyzer has detected one or more backup issues. [...]"
but log analysis text output is blank for all of them:
------ BEGIN OF ALICE RAW OUTPUT -----
------ END OF ALICE RAW OUTPUT -----
so I'm not attaching any logfile. Feel free to ask for them if needed.

nicholas
Akeeba Staff
Manager
Backup quotas are applied per profile, not globally. This means that if you have several backup profiles you need to set up quotas on each profile and it will only apply on the backup records of that specific backup profile.

Backup quotas only apply to backup records, not backup archives. This means that if a backup is NOT listed in the Manage Backups page Akeeba Backup does NOT know about it and it will NOT participate in quota management. Otherwise quota management would be too slow to be practical (in fact, it would cause the backup to crash). That's because discovering backup archives, especially on remote storage, is a time and memory intensive process. We have determined that when you store more than 50 backup part files on remote storage the time it takes to analyze them for quota management purposes is greater than the safe time limit of ~7 seconds (after which there's a > 10% chance of causing a backup failure due to timeout).

Backup quotas are applied, by default, to local files only. If you want remotely stored files, e.g. on Dropbox, to participate in quota management you MUST check the Enable Remote Quotas checkbox.

All of this information can be found in our documentation. Please consult the documentation, do not make assumptions on how things work. According to our experience, if you ask 10 people how quotas work you will get 12 different answers. Yes, more answers than the people you ask - true story! The way we have implemented quota management is how the majority of people expect them to work with the added twist that they are calculated against backup records in the database instead of files for the reasons I explained.

Regarding ALICE, it's designed to run against the log files of failed backup attempts only. If the backup is not failed it does get confused and produces nonsense results.

I hope this information helps!

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!

inlico
Thanks for your quick and thorough reply. Frankly, I didn't peruse all the documentation before posting, as I was just sharing my surprise in case that rang a bell. Otherwise all is working fine now, so I am closing the ticket.

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!