WPサイト容量が34GBから7.8GBに｜BackWPup更新後の保存先パス見落としを解消した事例

「またバックアップのエラーメールきました」って、保守でお預かりしているクライアントさんからご連絡をいただきました。

実は前回の対応からまだ数日。「また同じ症状？」と思いつつ確認に入ったんですけど、調べてみたらその日のエラー自体は一時的なネットワーク接続切れで、容量問題はクリアされていました。

ただ、調査ついでにサーバー内を見ていたら、思わぬ落とし穴を発見しました！

BackWPupプラグインの更新で、バックアップの保存先パスが新形式に変わっていたことが原因で、旧パスに 28GB 分のバックアップが残ったままになっていたんです。

結果として、サイト容量を 34GB → 7.8GB に削減＋将来的な容量超過の予防まで対応できた事例なので、同じくBackWPupでサイト運用している方の参考になればと公開します！

• バックアップエラーが「容量問題」じゃなかった話
• BackWPupプラグイン更新時の落とし穴（保存先パス変更）
• 実際の対応工程と数字（28GB削減・ジョブ整理・保存数自動制御）
• 今後の容量管理を「設定で自動化」した話

「またバックアップエラー出ました」の再発のご相談

• 対象サイト
  保守ではお預かりしていないWordPressサイト（さくらのレンタルサーバ／SnapUP使用）
• 症状
  さくらインターネットから「バックアップ＆ステージング機能のエラー」メールが届いた
• 前回対応
  数日前に容量超過対応（古いバックアップ削除）を実施済み
• クライアントさんよりご連絡
  「またバックアップのエラーメールきました…」とFacebook Messengerでご連絡

ここで「あれ、対応したばっかりだけど…」って一瞬思いますよね。
私もそうでした！

ただ、こういう時こそ「同じ原因の再発」を疑うより、まずは事実確認から入るのが大切です。

原因切り分けでは、エラー自体は容量問題ではなかった

さくら管理画面のスナップショット履歴を確認したところ、以下の状況でした。

日付	結果
前回対応の翌日	✅ 正常終了
その2日後	✅ 正常終了
エラー報告のあった日	❌ driver: bad connection（一時的な接続エラー）
翌日	✅ 正常終了（自然回復）

つまり、エラーが起きた日のメッセージは 「driver: bad connection」
これはデータベース接続が一瞬切れた、いわゆるネットワーク瞬断系のエラーで、前回対応した容量問題は既に解決していたことが確認できました。

翌日には自動で正常終了に戻っていたので、このエラー自体は再発でも放置でもなく、自然回復でOKという判断です。

ここで終わってもよかったんですが、せっかくサーバーに入って状態を見ていたので、ついでにサイト全体のバックアップ状況をチェックしてみたら…ここから本題が始まります。

BackWPupプラグイン更新で保存先パスが新形式に変わっていたことを発見

調査中、uploads/backwpup/ 配下を見ると、知らないフォルダ階層に大量のtarアーカイブが堆積していました。

• 旧パス: uploads/backwpup-{ハッシュ}-backups/
• 新パス: uploads/backwpup/{ハッシュ}/backups/

実はBackWPupプラグインがバージョンアップで保存先パスのルールを切り替えていて、新パスのほうに 28GB分（13ファイル）のtarアーカイブが残ったままになっていたんです。

前回の容量整理では旧パスのファイルだけ削除していたので、新パスはまるっと見落としていました。やられたー！って感じです。

さらに調査を進めると、こんな状況も発覚します。

• BackWPupジョブが 過去の運用で6個 混在（旧 legacy ・重複あり）
• 最新の Files ジョブには DBバックアップが含まれていない（type: FILE+WPPLUGIN のみ）
• 毎月1日に 2.4GBのtarが自動生成される設定
• 保存数の上限が 15世代 のままで、放置すると数ヶ月後に再度容量超過の可能性

古いバックアップ削除＋ジョブ整理＋保存数2に固定対応

せっかく見えた問題なので、根本対応まで一気に進めることにしました。クライアントさんからは「予防的なクリーンアップもお任せでOK」とご許可をいただいた上での実施です。

① 古いバックアップファイル削除（SSH経由）

1. 新パス側（uploads/backwpup/{hash}/backups/）
   13個中11個を削除し、直近2世代のみ残す → -25.5GB
2. 旧パス側（uploads/backwpup-{hash}-backups/）
   見落としていた古いDBダンプ2個を削除 → -3.6GB
3. ログフォルダも古い分を整理し、直近2件残す

② BackWPupジョブ整理（WP-CLI経由）

1. 旧 legacy・重複ジョブ5個（jobid: 1, 2, 4, 5, 5）を削除
2. 残した jobid:3 「Files」を 完全バックアップ化（type: DBDUMP+FILE+WPPLUGIN）
3. 保存数 maxbackups: 15 → 2 に変更（最新2世代のみキープで容量自動制御）

③ wp_cron 整理＋次回実行を再予約

1. 古い cron 予約3個を削除
2. jobid:3 用の次回実行を翌月1日 09:00 JST に再予約

---

結果として、サイト容量が 34GB → 7.8GB に削減・将来も自動制御

項目	Before	After
サイト総容量	34GB	7.8GB（-26GB）
BackWPupジョブ	6個（legacy混在）	1個（完全バックアップ化）
保存世代数	15	2（自動制御）
バックアップ種別	FILE+WPPLUGIN（DB含まず）	DBDUMP+FILE+WPPLUGIN
想定される最大容量	無制限に増加	約4.8GBで頭打ち

月次2.4GBのバックアップが生成されますが、保存数2の自動制御で容量は 約4.8GBに頭打ち。SnapUP 60GB制限に対しても大幅な余裕ができました。

「直したのに直ってない」って思った時こそ、隣の落とし穴を疑うという学び

今回いちばんの学びは、「同じエラーの再発に見えた時に、即同じ原因と決めつけない」ということでした。

実際にやってみると、

• 今回のエラー自体は別物（一時的な接続切れ）
• 本当の問題は別の場所に潜んでいた（プラグイン更新で保存先パス変更）
• 前回対応の盲点を補完するチャンスにもなった

と、最初に思っていたシナリオとは全然違う展開になりました。

プラグインのバージョンアップで 仕様や保存先がサイレントに変わる のは、WordPressあるあるです。BackWPupに限らず、SEOプラグイン・キャッシュ系プラグイン・セキュリティ系プラグインでも同じことが起きます。

だからこそ、「直したばっかりなのに同じ症状？」って思った時こそ、隣の落とし穴を疑う視点が現場では大事なんですよね。

ちゃんと届くようにする。これが私の軸なので、こうやって現場で見つけた小さな知見も、同じところで困っている方に届けばと思って公開しました。

サイト容量・バックアップ整理ご相談ください

今回の事例、心当たりある方はぜひ一度ご自身のWordPressサイトの以下を確認してみてくださいね。

• wp-content/uploads/ 配下にBackWPup関連フォルダが 2種類（旧パス／新パス）ないか
• BackWPupジョブが 過去の運用ぶん含めて重複 していないか
• 保存世代数が 大きすぎる設定（10以上）になっていないか

以下のような方は、お気軽にご相談ください！

• サーバーから「容量超過」のお知らせメールが届いている
• BackWPupは入れているけど中身を整理した記憶がない
• バックアップ周り、専門家に1回まとめて整えてほしい
• 月々の保守の中で、こういう小さな見落としを定期的にチェックしてほしい

💬 WordPressのバックアップ・容量管理、ご相談はお気軽に

こんたホームページ製作所では、サイト容量診断から月額保守でのご対応まで、各種承っております。「自分でSSHやWP-CLIを触るのは怖い」「業者に頼むほどでもない気がする」という規模感のお困りごとも、まずはサクッとご相談ください。

▶︎ ホームページ保健室で単発相談する
▶︎ 月額保守サービス（運用プラン）を見る
▶︎ お問い合わせはこちら