Support

The reason for quotas not being effective with cloud backup is that querying the cloud server for the count and size of existing backup archives is a very time consuming process which could lead to timeouts. To better understand how time consuming it is, try installing a desktop utility - such as CloudBerry - and get a listing of a S3 directory containing hundreds of files. It certainly takes its time!

Regarding the use of a static filename, yes it is possible. Even if your backup archive grows smaller (though I can't see how) Kickstart and eXtract are aware of this. I haven't tested this case, but as far as I can see, there should be no problem except with JPA archives, as they do not have an end-of-archive marker yet. However, it's rather easy to figure this out yourself. If you have extraneous backup parts they would have a timestamp much further in the past than the rest of your backup archive parts, so you don't need to download them.

The best approach I've found to manually managing quotas is doing some housekeeping. In any case, it's a good idea to keep the last week's or month's backups in the cloud, just in case your site was hacked in the meantime and you didn't catch wind of this issue. It's easier to start with a "last known good" state of your site and then start transferring changed data from the compromised site to the last known good state. In order to do this, keep on backing up your site daily to the cloud. Every week connect to your cloud storage with a desktop utility and remove old backup archives. After all, the default naming scheme includes host, date and time stamps in the archive name. Sorting the listing by name ascending is an easy way to have a per site and date ordered list which you can manage quite easily. Well, this is what I do :)