同様の問題が当方で再発しました。設定値を「3」に制限しているにもかかわらず、数十個のローカルバックアップ（各 1.6GB）が存在することに気づきました。これは長年正常に機能していましたが、以前にも同様の問題が発生したことを覚えています。
より良い機会に詳しく調査する必要があります。
@rizka へ
この問題は 9 月 11 日に発生しました。その日付は、当社のサービス停止やサイトへの何らかの変更とは一致しません。
これは孤立した事例ではなく、別の小さなサンドボックスインスタンスでも同様の問題が発生しているようです。こちらは完全に異なるインフラ（Digital Ocean 上でホスト）ですが、9 月 16 日以降バックアップが削除されていません。こちらもアップロードは正常に完了しています。
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.
この件についてはすっかり忘れていましたが、今確認しました。S3 には 97 個のバックアップが保存されていますが、設定は 30 に設定されています。
現在 2.3 ブランチを使用しており、まもなく 2.4 への更新を予定しています。
結局、この件は解決しましたか？
ああ、これは昔の話ですね。何らかの形で解決されたような気がしますが、私たちはもう何年もCDCK SaaSを利用しており、この問題についてはもうはっきりと思い出せません。
もしこれがまだ問題だったとしたら、他のセルフホスティング者が報告したのではないでしょうか？
まったく同じ問題を抱えていました。そして、過去10分間で、s3_disable_cleanup をオンにしてしまっていたことが原因だとわかりました。s3アップロードのみに関連し、バックアップには関係ないと思っていました。しかし、それは間違いでした。
