Support

No, the expire meta tag has an impact only to serving the files, not storing them. We do not support quotas on cloud storage services for several reasons, the most important being that it's impossible to reliably get a file listing without risking a timeout error. The only trick I've found (as I'm doing exactly what you describe) is to use one directory per site, then perform a manual clean-up of the backup archives (delete the old ones) every 2 weeks using CloudBerry Explorer for Amazon S3. Since the default backup naming scheme includes the date and time of the backup, this is fairly easy and doesn't take more than half a minute per site.

With DropBox it's very easy. Under most Operating Systems you can run a search against your local (synchronized) DropBox folder for file older than X days. Select all, delete. DropBox automatically synchronizes the deletes to their servers. Done :) If you are more tech-savvy you may even create a script to automatically run this procedure on your local DropBox folder every day.

It's already asked and I have already responded exactly why it can't be realiably implemented (unless you don't mind crashing your backup due to timeouts). Don't add it as a feature request, just browse the feature request forum and find my answer.

When you tell Akeeba Backup to keep, say, the 3 last backups it has to remove all the backup archives except those three. Since we may be talking about hundrends of records, if it tried to delete all of them it would time out. It would need a file listing to figure out which of them are present on the cloud storage service, which would also cause a timeout.

In the case of size quotas, the filesize is not cached in the database, mainly because of PHP internally using 32-bit signed integers except on the Linux x86-64 platform. This simply means that anything over 2Gb is unreliably calculated. So, the only way to figure out the backup size in order to apply quotas is, once more, file listings.

I could create a half-baked approach of only applying count quotas and supposing that all backups before the last 3 are deleted except the fourth, so I could only delete the files of that backup attempt. This causes two major problems:
- Most people wouldn't like the difference in functionality between local and cloud quotas, file it as a bug and ultimately ending up in causing me to remove this feature to stop explaining that it is not a bug
- Not all cloud storage services support file deletes. DropBox and backup-to-email most notably can't do that. Even those which can may not be allowed to do so due to ACLs. For example, I always use a write-only account to save my backup archives to S3. This account can neither list files nor delete them. This differences between each cloud storage engine would also cause support requests as people would consider them bugs when they're not.

So, the only sane approach is to not add a feature which would be inconsistent with how the rest of Akeeba Backup currently works, increase the support requests without adding signifficant value to the product and which can be substituted with an easy manual process.

Upon re-reading my post, I think I've found a solution which will make all of us happy. The idea is this:
- Each post-processing engine can define its own count quota handling settings and provide the relevant code to run it.
- The quota enforcement can run on a new step to avoid timeouts
- Using variables (e.g. [DATE], [TIME]) in directory names will render quotas ineffective, but this shouldn't be that big of a concern, because you'd only use them if you don't care about quotas :)
- For S3, the quota handling code will assume that only the last backup's files need to be removed, i.e. if you have a quota of 3 backups only the fourth backup will be removed
- Failure to delete due to ACL restrictions will be logged as a warning, not a fatal error, so it won't stop the process from completing.

Would that be a satisfactory solution?

Great! Added in the to-do list for version 3.2.

Remote quotas have been implemented, as promised, since Akeeba Backup 3.2. The latest version, Akeeba Backup 3.3.1, goes one step further. It now allows you to keep daily backups for a predefined period (e.g. the last 30 days) and keep the backups taken every Xth day of the month (e.g. every 1st of each months). This allows you to keep monthly backups forever and daily backups only for the last month. No need for s3cmd or any other tool; just Akeeba Backup all by itself :)