我们遇到了类似的重复问题。我刚刚发现本地有几十个备份（每个 1.6GB），而设置中限制保留的数量为 3。该功能多年来一直正常工作，但我记得很久以前曾发生过一次类似的问题。
需要找个更好的时间深入排查。
@rizka 请留意
问题始于 9 月 11 日。该日期与我们的服务中断或我们对网站进行的任何操作均不吻合。
这并非孤立案例，我的另一个小型沙箱实例似乎也存在同样的问题。该实例位于完全不同的基础设施上，托管在 Digital Ocean。在此实例中，备份自 9 月 16 日起未被删除。上传操作在此处也成功完成。
好吧……现在这看起来像是个愚蠢的用户错误——我完全忽略了备份管理目前的工作方式变化。所以 Discourse 现在直接管理和删除 S3 备份，无需通过存储桶规则来清理旧备份？现在将数值增加到 30，因为备份不应占用本地磁盘空间。
但存储在 S3 存储桶中的备份数量与设置值 3 并不一致。
我现在已将备份和存储桶规则重新配置为合理的值，以匹配当前的 Discourse 行为。正如之前所说，我之前将备份数量设置为 3，这是基于旧的备份逻辑。现在已将其设置为 30。
请保持该帖子开启，我将在 30 天后回复，以验证 Discourse 是否已正确遵循新定义的值。
之前忘了这个问题，但现在看了一下。我在 S3 中存储了 97 个备份，而设置值是 30。
目前仍在运行 2.3 分支，准备很快升级到 2.4。
出于好奇，你最终弄清楚了吗？
啊，这已经是陈年旧事了。我感觉这个问题好像已经解决了，但我们现在已经使用 CDCK SaaS 好几年了，我对这个问题已经没有清晰的记忆了。
我猜如果这仍然是一个问题，应该会有其他自托管用户报告吧？
我遇到了完全相同的问题，在过去的 10 分钟里，我发现原因是我不小心开启了 s3_disable_cleanup。我认为这只与 s3 上传有关，与备份无关。但事实并非如此。
