# Discourse not respecting the number of S3 backups to keep
**URL:** https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994
**Category:** Self-hosting
**Tags:** backups, s3
**Created:** [15 december 2019 om 10:10 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994 "2019-12-15T10:10:46Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@ljpp](https://meta.discourse.org/u/ljpp)
#### Post date: [15 december 2019 om 10:10 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/1 "2019-12-15T10:10:46Z")
> [@Backups are duplicating and not respecting number to keep on disk](https://meta.discourse.org/t/backups-are-duplicating-and-not-respecting-number-to-keep-on-disk/107427):
>
> @Wingtip Our Discourse instance recently has started to misbehave with regards to backups. Among other things, it’s taking backups twice a day when it is set to take them every other day and it is not respecting the setting we have in place to only maintain a single backup on disk. This is causing the disk to fill up with large backups, leading to subsequent backup failures. Here are our settings: Here’s some of the recent backup activity: This results in inadequate sp…
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.
Need to dig in deeper at a better time.
Ping @rizka
### Update:
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.
---
### Author:  [@ljpp](https://meta.discourse.org/u/ljpp)
#### Post date: [16 december 2019 om 14:36 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/2 "2019-12-16T14:36:13Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [16 december 2019 om 23:53 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/3 "2019-12-16T23:53:35Z")
I have no issue with AWS S3 backups on my self hosted instance:
---
### Author:  [@ljpp](https://meta.discourse.org/u/ljpp)
#### Post date: [18 december 2019 om 19:30 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/4 "2019-12-18T19:30:47Z")
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.
---
### Author:  [@ljpp](https://meta.discourse.org/u/ljpp)
#### Post date: [19 maart 2020 om 20:08 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/5 "2020-03-19T20:08:28Z")
Forgot about this issue, but now had a look. I have 97 backups stored in S3 while the setting is at 30.
Still running the 2.3 branch, preparing to update to 2.4 soon.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [18 maart 2024 om 19:19 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/6 "2024-03-18T19:19:23Z")
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [18 maart 2024 om 19:32 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/7 "2024-03-18T19:32:39Z")
Out is curiosity, did you figure this out in the end?
---
### Author:  [@ljpp](https://meta.discourse.org/u/ljpp)
#### Post date: [10 april 2024 om 19:34 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/8 "2024-04-10T19:34:47Z")
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?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [10 april 2024 om 20:03 UTC](https://meta.discourse.org/t/discourse-not-respecting-the-number-of-s3-backups-to-keep/135994/9 "2024-04-10T20:03:48Z")
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.