WordPressバックアップが失敗・停止したら？AIと安全に原因を調べる方法

WordPressの更新前にバックアップを始めたものの、進行表示が止まる、失敗メールが届く、保存先にファイルが見当たらない――。この状態で何度も再実行すると、サーバー容量をさらに使ったり、不完全なファイルが増えたりすることがあります。

大切なのは、エラーを見てすぐ設定を変えることではありません。まずどの工程で止まり、何が残り、最後に成功したバックアップはいつかを確認します。

この記事では、CodexやClaude Codeを調査の補助に使いながら、ITに詳しくない宿主さんでも安全に状況を整理できる方法を説明します。

結論：再実行する前に「止まった場所」と「戻れる世代」を確認する
バックアップは複数の工程でできている
よくある原因候補
最初に宿主さんが確認すること
1. 本番サイトが動いているか
2. 失敗の記録を残す
AIには最初に「読み取りだけ」を頼む
不完全ファイルを完成品として扱わない
容量不足を調べるときの注意
通信・時間制限で止まる場合
更新され続けるファイルの警告
コピペで使えるAIへの依頼文
続行してよい変更と、止めるべき変更
宿主さん向け確認チェックリスト
参考にした公式情報
まとめ

結論：再実行する前に「止まった場所」と「戻れる世代」を確認する

最初の対応は次の順番です。

バックアップの再実行をいったん止める
エラーが出た日時と工程を記録する
本番サイトが正常に表示されるか確認する
不完全なファイルが残っているか調べる
直近の成功済みバックアップを確認する
容量、権限、通信、時間制限を読み取り調査する
原因に合った一つの対処だけを試す
成功後に整合性と復元可能性を確認する

バックアップに失敗した状態で、WordPress本体、テーマ、プラグイン、PHPの更新へ進んではいけません。更新に失敗したときの戻り道が確認できていないためです。

バックアップは複数の工程でできている

「バックアップが止まった」といっても、止まる場所は一つではありません。

対象を確認
  ↓
データベースを書き出す
  ↓
画像・テーマ・プラグイン等を集める
  ↓
圧縮または暗号化する
  ↓
別の保存先へ転送する
  ↓
破損していないか検査する
  ↓
古い世代を整理する

データベースの書き出しは終わっていても、転送で止まることがあります。保存先にファイルがあっても、検査前なら完成品とは限りません。「ファイル名があるから成功」と判断しないようにします。

よくある原因候補

原因候補	見つかる手掛かり	最初の安全な確認
容量不足	書き込みエラー、途中で急停止	サーバーと保存先の空き容量を読む
書き込み権限	保存先を作れない	対象フォルダの所有者・権限を読む
実行時間・メモリ	一定時間で止まる、504等	契約先の制限とログの該当時刻を確認
通信切断	外部保存先への転送で止まる	接続結果、再試行、保存先サービス状況を確認
ファイルの変化	圧縮中に警告が出る	キャッシュやログ等、更新され続ける対象を確認
巨大ファイル・DB	毎回同じ対象で止まる	容量の大きい対象を一覧化する
保存先の認証	期限切れ、認証エラー	公式管理画面で接続状態を確認
同時実行	複数処理が重なる	スケジュールと実行中ジョブを確認

この表は原因を断定するものではありません。たとえば「転送中に止まった」場合でも、通信だけでなく転送元の読み取り、保存先容量、認証期限など複数の可能性があります。

最初に宿主さんが確認すること

本番サイトが動いているか

トップページが開く
予約ボタンが表示される
問い合わせ方法が確認できる
WordPress管理画面へ通常どおり入れる

サイト自体も止まっている場合は、バックアップ調査だけの問題ではありません。予約経路を確保し、レンタルサーバー会社または保守担当者へ連絡します。

失敗の記録を残す

実行開始・停止日時
手動実行か自動実行か
画面に表示された短いエラー文
どの工程まで進んだように見えたか
直前に変更した設定やプラグイン
最後に成功した日時

スクリーンショットには管理画面URL、利用者名、保存先アカウント、ファイルパス、認証情報が写る場合があります。共有前に伏せます。

AIには最初に「読み取りだけ」を頼む

AIへ「バックアップを直して」とだけ頼むと、古いファイルの削除、権限変更、タイムアウト値の拡大などをすぐ提案する場合があります。先に調査範囲を限定します。

読み取り調査で確認できる項目は次のとおりです。

サーバーと保存先の空き容量
バックアップファイルの日時・サイズ・状態
不完全ファイルの有無
直近の検証済みバックアップの有無
実行時刻付近のエラー種類
バックアップ処理の開始・終了状態
同じ時刻に動いた別処理
対象データの大きさ
契約サービスの制限と公式案内

ログ全文をAIへ渡す必要はありません。発生時刻付近から、秘密情報を除いた必要部分だけを使います。

不完全ファイルを完成品として扱わない

途中まで作られたファイルには、.part、.tmpなどの印が付く場合があります。ただし名称はバックアップ製品やスクリプトによって異なります。

不完全ファイルを見つけても、すぐ削除しません。

実行中の処理が本当に終了しているか確認する
その製品が再開用に使うファイルではないか公式資料で確認する
ファイルの場所、日時、サイズだけを記録する
直近の完成済み世代が別に残っているか確認する
削除が必要なら対象を明示し、人が承認する

広いフォルダをまとめて削除する命令や、名前が曖昧な一括削除をAIへ許可してはいけません。

容量不足を調べるときの注意

バックアップは元データを読むだけでなく、一時ファイルの作成や圧縮にも空き容量を使います。保存先に余裕があっても、処理するサーバー側が不足することがあります。

容量が少ないと分かっても、AIへ古い画像、データベース、ログを自動削除させません。次を分けて一覧化します。

WordPressのアップロード画像
バックアップの完成済み世代
不完全な一時ファイル
キャッシュ
ログ
サーバーの他サービスが使うデータ

どれを消せるかは役割、保存義務、復旧への影響を確認して判断します。特に完成済みバックアップを先に消すと、唯一の戻り道を失う可能性があります。

通信・時間制限で止まる場合

外部ストレージへの転送や大きなデータベース処理は時間がかかります。一方、画面が静かなだけで裏側の処理が続いている場合もあります。

次を確認します。

処理が今も実行中か
最後にログが更新された時刻
転送済みサイズが変化しているか
自動再試行の仕組みがあるか
レンタルサーバーの実行時間・メモリ制限
外部保存先の障害情報

根拠なく実行時間やメモリ上限を大きくすると、サーバー全体が重くなることがあります。レンタルサーバーでは契約先の推奨設定を確認し、VPSでは保守担当者が資源状況と影響を確認します。

更新され続けるファイルの警告

バックアップ中も、アクセスログ、キャッシュ、セッション、一時ファイルなどは変化することがあります。その結果、「読み取り中にファイルが変わった」という警告が出る場合があります。

この警告を無視してよいかは、対象によります。

キャッシュなど再生成できるものか
記事画像や設定など復元に必要なものか
データベースは一貫した方法で書き出せたか
製品の公式資料で除外対象として案内されているか

AIにファイル名だけで判断させず、役割と復元時の必要性を確認します。

コピペで使えるAIへの依頼文

変更せず原因候補を整理する

WordPressのバックアップが途中で停止しました。
まだ再実行、削除、権限変更、設定変更をしないでください。

発生日時: ［日時］
停止したように見える工程: ［工程］
表示されたエラー: ［秘密情報を除いた短い文］

読み取りだけで、空き容量、不完全ファイル、直近の成功済み世代、
実行状態、該当時刻のエラー種類を確認する計画を作ってください。
事実、推測、未確認事項を分けて報告してください。
秘密情報やログ全文は表示しないでください。

再実行してよいか判断する

バックアップ失敗の調査結果は次のとおりです。
［確認できた事実］

まだ実行しないでください。
再実行する条件、中止する条件、必要な空き容量、
不完全ファイルの扱い、成功後の検査を整理してください。
削除や設定変更が必要な場合は、対象と影響を一件ずつ示し、
私の承認が必要な項目として分けてください。

保守会社へ渡す報告を作る

バックアップ失敗について、レンタルサーバー会社または保守担当者へ
送る問い合わせ文を作ってください。

発生日時、再現状況、停止工程、短いエラー、最後の成功日時、
実施済みの読み取り確認を含めてください。
パスワード、秘密鍵、内部パス、顧客情報は含めないでください。
こちらで無断変更していないことも明記してください。

続行してよい変更と、止めるべき変更

バックアップが失敗したままでも、すべての作業が同じ危険度とは限りません。

作業	判断の目安
誤字修正や新規記事の追加	直近の検証済み世代があり、変更が容易に戻せるなら個別判断
可逆的な表示設定	変更前の値を記録し、影響が限定的なら個別判断
WordPress・テーマ・プラグイン更新	原則として成功済みバックアップを確認するまで停止
PHP・データベース更新	停止
DB移行・一括置換	停止
大量削除・容量整理	停止し、対象と復元可能性を確認