20GB のバックアップを Wasabi S3 に送信するサイトを持っています。通常は動作しますが、時々アップロードに失敗し、ローカルの .tar.gz ファイルが残ったままになります。その結果、最終的にディスクがいっぱいになり、圧縮版の保存スペースが不足していたため圧縮されていない .tar ファイルが残った状態で、ディスクがいっぱいになってサイトが機能しなくなります。
Wasabi を見送る前に、何か手がかりがないか確認してみたいと思います。
production.log、production.errors、Sidekiq および Unicorn のログを確認しましたが、バックアップが失敗した日や成功した日のいずれにおいても、「acku」という文字はどこにも見つかりませんでした。どこかにログが残るべきではないでしょうか？
失敗した場合は、PM にログ出力が届くはずです。UI での手動バックアップの場合は直接あなたに、自動バックアップの場合は管理者グループに送信されます。
バックアップ中の例外は /logs にも表示されるはずです（おそらくログファイル内にも）。EXCEPTION: で検索してみてください。
ただし、一時ファイルがそのまま残っている事実から、バックアップ中に Sidekiq、あるいは Docker やホスト自体が再起動していないか疑問に思います。それが、クリーンアップが実行されない理由や、PM が届かない理由を説明するかもしれません。
はい、これは非常に奇妙です。.tar ファイルのみでディスクがほぼ満杯だったケースを含め、失敗通知は一切届いていません（tests-passed 上の最新サイトです）。
まるでその数日間だけ backup location が変更されたかのような状況ですが、ログには何も記録されていません。Web インターフェースから開始されたバックアップについては、管理メッセージに「成功」の通知は表示されますが、失敗の通知はありません。そのため、backup_location を環境変数（ENV）設定に変更しました。
もしかすると、Wasabi を完全に諦めるのはまだ早いかもしれません…
ありがとう、Gerhard！