All-in-One WP Migrationでバックアップの削除・作成を行ったところ、サーバー上の全サイトが約3時間にわたって504 Gateway Timeoutで接続不能になりました。
この記事では、実際に起きた障害の状況・観測と原因候補・試した対処法・再発防止の確認項目をまとめます。
今504が出ているときに確認すること
504はゲートウェイが上流の応答を待ち切れなかったことを示し、それだけでは特定のプラグインや削除処理を原因と確定できません。
同じ作成・削除操作を繰り返さず、発生時刻、エラーログ、CPU・メモリ・I/O、実行中ジョブを管理者またはホスティング会社に確認します。
この記録にはCPU高負荷の時間帯と接続不能の時間に差があり、同じ3時間の事象としては扱いません。
PHPの切り替えやプロセス停止は他の処理にも影響するため、原因を確認せず繰り返す対処にはしません。
再開する場合は低負荷の検証環境で一つの処理ずつ確認し、残すバックアップと復旧方法を先に決めます。
今回、削除・バックアップ作成・障害の再現は行っておらず、当時の原因は未確定です。
起きたこと
All-in-One WP Migrationのバックアップファイルを8つ削除し、続けて最新のバックアップを新規作成したところ、操作直後からサイトにアクセスできなくなりました。
具体的な症状は以下のとおりです。
- 該当サイトだけでなく、同一サーバー上の全サイトが504 Gateway Timeoutを返す
- 管理画面（wp-admin）にもアクセスできない
- 約3時間後に自然復旧
サーバーのリソース状況
サーバーのリソースモニターを確認すると、高負荷が同時期に記録されていました。
- CPU使用率：21時頃から約100%に張り付き、3時頃まで継続（通常時は平均9.5%）
- メモリ使用率：同じタイミングで100%に到達（通常時は平均47%程度）
レンタルサーバー側からも「現在のベーシックプランではリソースが不足しています」という警告が表示されていました。
試した対処法（効果なし）
復旧を試みて以下の操作を行いましたが、いずれも効果はありませんでした。
- プラグインの無効化：FTPやファイルマネージャーからAll-in-One WP Migrationのプラグインフォルダをリネームして無効化 → 変化なし
- PHPバージョンの変更：サーバーパネルからPHPバージョンを切り替え → 変化なし
これらの操作では表示が戻りませんでした。高負荷は観測していますが、実行中プロセスの記録がないため、どの処理が負荷を占めていたか、操作が効かなかった理由は確定できません。
結局、約3時間後に自然復旧したという結果になりました。
原因候補と未確認の点
今回の記録から考えられる原因候補を整理します。
削除と新規作成の影響を分けて調べる
バックアップの削除と新規作成は負荷の原因候補です。ただし、当時の実行ログがないため、8つの削除処理と作成処理が同時に動いていたか、CPU・メモリ・I/Oのどれが制限に達したかは未確認です。
確認すべき処理の候補は次のとおりです。今回、各処理のCPU・メモリ・ディスクI/Oへの影響は測定できていません。
- 大容量ファイルの削除に伴うディスクI/O
- バックアップ作成時のデータベースダンプ処理
- アーカイブ作成処理（圧縮方式や負荷の内訳は未確認）
ベーシックプランのリソース上限
利用しているサーバーのCPU・メモリ等の制限を、契約仕様と管理画面で確認します。制限の単位や公開されている項目はサービスによって異なります。
通常運用時の値だけでは、バックアップなどの処理中に上限へ達するかは判断できません。
そして共用サーバーでは同一アカウントのリソースが共有されるため、同じリソース制限を共有する他サイトにも影響する場合があります。
今後の対策
原因の調査と並行して、次の運用を見直します。今回の障害を再現して効果を確かめた対策ではなく、各環境で確認する候補です。
1. バックアップの一括削除を避ける
削除と新規作成を続けて実行せず、処理の終了と負荷を確認します。何個までなら安全かは、ファイル容量やサーバーの制限で変わります。保存すべきバックアップと復元方法を先に確認してください。
2. バックアップ操作はアクセスの少ない時間帯に行う
深夜帯でも他のcron処理（自動バックアップ、メール配信など）と重なる可能性があるため、サーバー負荷が低いことを確認してから操作する。
3. 不要なバックアップは日常的に整理する
溜め込んでから一気に削除するのではなく、新しいバックアップの復元可能性と保持期間を確認してから、不要になったものを整理するルーティンにする。
4. サーバープランの見直し
平常時と障害時の利用量、上限に達した項目、同時に動く処理をサーバー会社へ確認します。容量やリソースの不足が確認できた場合に、プラン変更や処理の分散を検討します。プラン名だけで不足や復旧を判断しません。
5. バックアッププラグインの見直し
別のバックアップ方式を検討する場合は、同じ対象データで処理時間・負荷・復元方法を比べます。プラグインを変更するだけで負荷が下がるとは限りません。以下も導入前に確認する候補です。
- UpdraftPlus：バックアップの分割処理に対応しており、分割時の負荷は環境ごとの確認が必要
- BackWPup：外部ストレージ（Dropbox、S3など）への直接バックアップに対応
まとめ
| 項目 | 内容 |
|---|---|
| 同時期の観測（因果は未確定） | バックアップ操作と同時期にCPU・メモリ高負荷を観測（因果は未確定） |
| 影響 | 同一サーバーの全サイトが約3時間 504 Gateway Timeout |
| 効果なし | プラグイン無効化、PHPバージョン変更 |
| 復旧 | 約3時間後に自然復旧（プロセスの終了は未確認） |
| 対策 | バックアップの一括操作を避ける・プラン見直し・プラグイン変更の検討 |
バックアップは「安心のための操作」のはずが、やり方を間違えるとサイト全体をダウンさせるリスクがあります。
共用サーバーでは特に、リソースを意識した慎重な操作を心がけましょう。
証明書警告や白画面も出る場合は、DNS・TLS・HTTP応答を順に切り分ける手順を参照してください。
