Similar issue has re-occurred for us. Just noticed I have dozens of local backups (1.6GB each), while the setting is restricted to value 3. This has worked for years, but I do recall one incident a long time ago when a similar issue happened.
Backups complete successfully
Uploads to S3 are successful
Running the stable branch. Just upgraded to 2.3.7 and rebooted.
The issue has started on 11th of September. That date does not match to our service breaks or anything we would have done for the site.
Update:
This is not an isolated case, as my other small sandbox instance has the same issue, it seems. This is in completely different infrastructure, hosted at Digital Ocean. Here the backups have not been deleted since September 16th. Uploads are successful here as well.
Okay…now this is starting to look like a stupid user error – I have completely missed the change in how the backup management is currently working. So Discourse now manages and deletes S3 backups directly, without the need to purge the old backups with a bucket rule? Now increasing the value to 30, as backups should not eat up local disk space.
The number of backups that were stored in the S3 buckets did not match the setting 3 though.
I have now reconfigured backups and bucket rules to sane values, matching the current Discourse behavior. Like said, I had the number of backups set to 3, based on the old logic of backups. Now it is set at 30.
Please keep the thread open, and I’ll report back in 30 days to verify that Discourse now respects the re-defined new value.
Ah, this is ancient history. I have feeling that it was resolved somehow, but we have been on CDCK SaaS for some years now and I have no clear recollection of this issue anymore.
I’d guess ot would be reported by some other selfhoster, if this was still an issue?
I just had exactly the same problem and in the last 10 minutes figured out that the reason was that I had somehow turned on s3_disable_cleanup. I think it had to do only with s3 uploads, not backups. But that was wrong.
