全自動バックアップシステムが稼働し始め、順風満帆に見えた矢先、定期報告のメールを見て顔が青ざめました。ある特定のクライアントサイトのバックアップファイルが、1回あたり「7.7GB」という規格外の巨体で生成されていたのです。

原因は、約57のサブサイトを抱える大規模な「WordPressマルチサイト」環境でした。このペースでバックアップを取り続けると、あっという間にサーバーのディスク容量を食いつぶしてしまう「容量の壁」にぶつかったのです。

AIと協議し、以下の二重安全弁（ダブルセーフティ）をスクリプトに組み込みました。

日数ベースの自動消去（RETENTION_DAYS）: 生成から30日が経過した古いバックアップファイル（.tar.gz / .sql.gz）を find -mtime +30 で全自動で検索・削除するクリーンアップ機能（prune_by_age）を実装。

世代管理とのハイブリッド運用: 従来の「直近N件残す」という世代数管理と、今回の「30日経過で消す」という日数管理を並存させ、どちらの条件でも確実に古いファイルが消える仕組みを構築。

あえて画像メディアフォルダ（uploads）をバックアップから除外せず、30日ローテーション（常に直近2世代・約16GB程度を維持）に収めることで、復元性を完璧に保ったまま容量の爆発を食い止めることに成功しました。

編集後記：
朝起きて「7.7GB」の文字を見た瞬間は、完全に時が止まりました。「え、これ何回か走ったらサーバー爆発しない……？」と冷や汗がドバッ。容量計算とスクリプト改修が無事に終わった時は、胸のつかえがスッと降りました。