All-in-One WP Migrationでバックアップの削除・作成を行ったところ、サーバー上の全サイトが約3時間にわたって504 Gateway Timeoutで接続不能になりました。
この記事では、実際に起きた障害の状況・観測と原因候補・試した対処法・再発防止の確認項目をまとめます。
起きたこと
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バージョンを切り替え → 変化なし
いずれもサーバーのプロセス自体がCPU/メモリを食い尽くしている状態だったため、プラグイン単体の操作では解消できなかったと考えられます。
結局、約3時間後に自然復旧したという結果になりました。
原因候補と未確認の点
今回の記録から考えられる原因候補を整理します。
削除と新規作成の影響を分けて調べる
All-in-One WP Migrationのバックアップファイルはサイズが大きく（数百MB〜数GB）、8つの削除処理＋新規バックアップの作成が同時並行的にサーバーリソースを消費したと考えられます。
とくに以下の処理がCPU・メモリを圧迫します。
- 大容量ファイルの削除に伴うディスクI/O
- バックアップ作成時のデータベースダンプ処理
- アーカイブ作成処理（圧縮方式や負荷の内訳は未確認）
ベーシックプランのリソース上限
共用レンタルサーバーのベーシックプランでは、1アカウントあたりのCPU・メモリに上限があります。
通常運用では問題なくても、重い処理が重なると簡単に天井に達します。
そして共用サーバーでは同一アカウントのリソースが共有されるため、同じリソース制限を共有する他サイトにも影響する場合があります。
今後の対策
同じ事態を防ぐために、以下の対策が有効です。
1. バックアップの一括削除を避ける
大量のバックアップファイルを一度に削除せず、1〜2個ずつ時間を空けて削除する。削除と新規作成を同時に行わないことも重要です。
2. バックアップ操作はアクセスの少ない時間帯に行う
深夜帯でも他のcron処理（自動バックアップ、メール配信など）と重なる可能性があるため、サーバー負荷が低いことを確認してから操作する。
3. 不要なバックアップは日常的に整理する
溜め込んでから一気に削除するのではなく、新しいバックアップの復元可能性と保持期間を確認してから、不要になったものを整理するルーティンにする。
4. サーバープランの見直し
サーバー側が推奨する上位プラン（プレミアムなど）への変更を検討する。とくに複数サイトを運用している場合、ベーシックプランでは日常的にギリギリの可能性があります。
5. バックアッププラグインの見直し
All-in-One WP Migrationはサイト移行には便利ですが、定期バックアップ用途にはサーバー負荷の低い代替プラグインを検討するのも手です。
- UpdraftPlus：バックアップの分割処理に対応しており、分割時の負荷は環境ごとの確認が必要
- BackWPup：外部ストレージ（Dropbox、S3など）への直接バックアップに対応
まとめ
| 項目 | 内容 |
|---|---|
| 同時期の観測（因果は未確定） | All-in-One WP Migrationのバックアップ8個削除＋新規作成でCPU/メモリ100% |
| 影響 | 同一サーバーの全サイトが約3時間 504 Gateway Timeout |
| 効果なし | プラグイン無効化、PHPバージョン変更 |
| 復旧 | サーバープロセスの自然終了を待つ（約3時間） |
| 対策 | バックアップの一括操作を避ける・プラン見直し・プラグイン変更の検討 |
バックアップは「安心のための操作」のはずが、やり方を間違えるとサイト全体をダウンさせるリスクがあります。
共用サーバーでは特に、リソースを意識した慎重な操作を心がけましょう。
再発時は連続操作を止めて記録する
504はゲートウェイが上流の応答を待ち切れなかったことを示し、それだけでは特定のプラグインや削除処理を原因と確定できません。
同じ作成・削除操作を繰り返さず、発生時刻、エラーログ、CPU・メモリ・I/O、実行中ジョブを管理者またはホスティング会社に確認します。
この記録にはCPU高負荷の時間帯と接続不能の時間に差があり、同じ3時間の事象としては扱いません。
PHPの切り替えやプロセス停止は他の処理にも影響するため、原因を確認せず繰り返す対処にはしません。
再開する場合は低負荷の検証環境で一つの処理ずつ確認し、残すバックアップと復旧方法を先に決めます。
今回、削除・バックアップ作成・障害の再現は行っておらず、当時の原因は未確定です。
