同様の問題が当方で再発しました。設定値を「3」に制限しているにもかかわらず、数十個のローカルバックアップ（各 1.6GB）が存在することに気づきました。これは長年正常に機能していましたが、以前にも同様の問題が発生したことを覚えています。
より良い機会に詳しく調査する必要があります。
@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アップロードのみに関連し、バックアップには関係ないと思っていました。しかし、それは間違いでした。
