Support

You are wrong. I think you do not understand how this feature works. Please do read the documentation:

Quotas let you automatically remove backup archives and / or backup records based on specific criteria. Quotas are always calculated against the backup records, not the backup archives on disk or on remote storage. In other words, if you do not see a backup record in the Manage Backups page it is NOT taken into account when applying quotas.

Furthermore, quotas will take into account only the backup record, without checking if the file exists. If a backup is listed as OK or Remote in the Manage Backups page it participates in the quotas.

The quotas apply per backup profile. They will only take into account backup records in the same backup profile.

Finally note that the quotas are only being applied at the end of a successful backup, even if post-processing (transferring it to remote storage) failed. It is therefore recommended that you keep an eye out for failed transfers – appearing as warnings in the backup logs and the CLI backup script's output – to avoid an over-zealous quota setting from removing your last full, good backup.

If your backup record is marked as OK (local file quotas, remote quotas) or Remote (remote quotas only) it is taken into account. It doesn't matter if it's split or not; we count backup records, not backup archive part files.

TL;DR: I have proven with facts, manual testing, unit testing, and integration testing that you are wrong. You have a misconfiguration and/or misunderstanding. I am giving you a list of common misconfigurations, and I am drawing your attention to a common misunderstanding.

I wasn't being dismissive. I had it on good authority with independent evidence, unit tests, and integration tests that the problem does not exist.

I, like hundreds of thousands of Akeeba Backup users, am using the same configuration you reported for my dev sites: split archives, count quotas. If there was a bug there I would've noticed.

Beyond that, when you reported this I wanted to be sure beyond my lived experience and my manual tests on a site that has a long backup history which could potentially muddle the results.

I wrote automated tests for precisely this scenario, at two levels. One runs the quota code in isolation (unit test) against many combinations of split and single-file backups. The other provisions a throwaway Joomla site, takes three real backups split into 22 archive parts each with a count quota of two, and then inspects both the database records and the files on disk.

Splitting makes no difference whatsoever. The two newest backup records survive, the oldest is made obsolete, and all 22 of its part files — the .jpa and every single .j01, .j02, … — are deleted. The exact same fixture with single-file backups expires exactly the same records. There is no code path in which the number of archive parts can influence which backups a quota removes. These tests are in Akeeba Backup's repository, part of the test suite that runs on every release, so this stays true in future versions.

That means the difference between that site and your others is something else. Here is what to check on the affected site, in the order I would check it:

1.  Configuration → Quota management → "Enable maximum backup age quotas". If this is on, the count and size quotas are ignored entirely. They are not combined; the age quota replaces them. (The option's own description says so in capitals, which tells you how often I had to state this before I added this ALL CAPS message.)
2. Configuration → "Backup archive name". If your naming template has no [DATE], [TIME] or similar variable in it, every backup writes to the same filename. All those backup records then point at the same file, and quotas see them as a single backup. This is also the one thing that would genuinely behave differently for split archives: when a later backup has fewer parts than an earlier one, the surplus .j0x files from the earlier backup are left orphaned on disk with no record owning them — which would look exactly like "quotas don't work when backups are split". If your template is missing a date/time variable, that is almost certainly your answer. Remember, folks. Default values in my software are there for a reason.
3. Manage Backups → any backup marked Frozen is deliberately excluded from quota management, and stays on disk forever until you unfreeze it. This is the very definition of what Frozen does: these records do not participate in quota management.
4. Quotas only ever consider backups of the same backup profile as the backup that just ran, with a status of Complete or Remote and their files still present. You dismissed me when I told you to look at the documentation which makes this point, but are you really aware of it?

If none of those explain it, the log will. Please set Configuration → Log Level to "All Information and Debug", take one backup on that site, then send me the log file from Manage Backups. Near the end you will see lines such as "Applying local quotas", "Processing local count quotas", "There were no old backup records to apply local quotas on" or "Excluding frozen backup id … from local quota management". Those tell me in one glance which branch ran and why, and I can give you a definitive answer instead of a list of things to check.

Attachments are private, even in public tickets. Only you and me can download them. Put your log file in a ZIP archive, attach it to your next reply.

The backup never finished. It only uploaded two files, the .jps and the .j01. However, it never managed to upload the .j02 file, and it never managed to run the subsequent post-upload finalization steps – including the quota management.

The root cause is what I've already documented:

Most failed uploads are caused by timeouts. PHP and your web server have time limits, i.e. the maximum time a PHP script may process data before the web server aborts it. Uploading the backup archives to cloud storage takes time, the exact amount of which depends on the size of the file and the network speed. If that time is over either time limit your backup will fail. The time limit and the bandwidth are beyond our control. The only thing you can control is the size. Many post-processing engines support chunked uploading (breaking up the uploads in smaller bits and having the remote server piece together the file) and you can change their chunk size. A chunk size of 5 or 10 MB works best in most cases. For those post-processing engines which don't have an option for chunked uploads you will have to change the Part size for split archives in the Archiver Engine options. Again, a value of 5 or 10 MB works best in most cases. This setting will split our backup archive into multiple files (same base filename, the extensions are .j01, .j02, ..., .jpa; or .j01, .j02, ..., .jps; or .z01, .z02, ..., .zip;), the maximum size of each one being the value of this setting. To restore these backups just place ALL of these files in the same directory and choose the main .jpa, .jps or .zip file: the other parts are discovered and extracted automatically.

SFTP does not allow chunked file uploads. It can only upload them as a one-shot attempt. With your current settings it takes over 5 minutes to upload the .j01 file over SFTP. This is too long for Panopticon. It times out, assumes your backup is stuck, and gives up. That's why your backup is not uploaded, that's why quota management never ran.

You need to reduce your split size to one tenth of what it is today to keep the individual upload time under a minute for this to work reliably. According to your log, your current split size is 1073741824 bytes (1 Gigabyte). Therefore, you need to set it to about 100 Megabytes. This will of course generate about 25 backup archive part files, not three. Do keep in mind that this setting is per backup profile. You need to change it in all of your backup profiles.