WordPressのバックアップ復元が途中で止まった事例
WordPressのバックアップデータを復元していると、
- 「途中から進まなくなった」
- 「読み込み中のまま終わらない」
- 「エラーも出ていないので、何を確認すればいいのか分からない」
ということがあります。
今回は、以前保存していたWordPressのバックアップデータを、All-in-One WP Migrationを使ってローカル環境へ復元したときに発生したトラブルを紹介します。
復元作業を進めると、途中で
「ブログの準備を完了しました。」
という表示から先へ進まなくなりました。
復元画面だけを見ると原因が分かりませんでしたが、別のタブでローカルサイトを開いたところPHPエラーが表示され、そこから原因となっているプラグインを確認できました。
この記事では、
復元が止まる → 別タブでエラーを確認 → 原因プラグインを特定 → ローカル環境で停止 → WordPressを復旧
という実際の流れを紹介します。
なお、今回紹介するのはローカル環境で行った作業です。本番公開中のWordPressサイトを直接操作した事例ではありません。

1.All-in-One WP Migrationでバックアップを復元する
今回は、以前保存していたAll-in-One WP Migrationのバックアップデータを、ローカル環境に作成したWordPressへ復元しました。
All-in-One WP Migrationは、WordPressサイトのデータをエクスポート・インポートできるプラグインです。
サイトの移行やバックアップデータからの復元などに利用できます。
今回使用したバックアップデータは以前作成したもので、復元作業には当時使用していた古いバージョンのAll-in-One WP Migrationを利用しました。
なぜ古いバージョンを使っていたのか
今回古いバージョンを使用していたのは、バックアップファイルの容量が大きかったためです。
All-in-One WP Migrationはバージョンや利用環境によってインポートできるファイル容量に制限があり、以前の環境では容量の大きなバックアップデータを扱うために古いバージョンを使用していました。
ただし、この記事では古いバージョンのAll-in-One WP Migrationを利用することをおすすめしているわけではありません。
古いプラグインには、
- 現在のWordPressとの互換性
- PHPとの互換性
- セキュリティ
- 他のプラグインとの組み合わせ
などの問題が発生する可能性があります。
今回はあくまで、過去のバックアップデータをローカル環境で確認するために使用した事例として紹介します。

2.「ブログの準備を完了しました。」から進まなくなった
バックアップデータをインポートし、復元処理を進めていきました。
途中までは正常に進んでいましたが、
「ブログの準備を完了しました。」
と表示されたところで処理が止まりました。
しばらく待っても読み込み中の表示が続き、復元完了画面へ進みません。
この時点では、All-in-One WP Migrationの画面上に分かりやすいエラーは表示されていませんでした。
そのため、
「バックアップファイルが壊れているのか」
「All-in-One WP Migrationが止まっているのか」
「WordPress側で何かエラーが起きているのか」
を判断できない状態でした。

3.復元画面を閉じずに別のタブでサイトを確認する
復元画面ではエラー内容が分からなかったため、復元中のタブはそのまま残し、別のタブでローカルサイトを開いてみました。
すると、別タブではPHPエラーが表示されていました。
ここが今回の原因を見つける大きな手がかりになりました。
All-in-One WP Migrationの画面が読み込み中になっている場合でも、WordPress側ではすでにエラーが発生していることがあります。
そのため、復元処理が長時間進まない場合は、すぐに画面を閉じるのではなく、別のタブでサイトやWordPress管理画面を開いて状態を確認するのも一つの方法です。

4.エラー文から原因となっているプラグインを確認する
PHPエラーには、エラーが発生したファイルの場所が表示されることがあります。
今回表示されたエラーにも、
wp-content/plugins/
以下のファイルパスが含まれていました。
この部分を見ることで、WordPress本体ではなく、特定のプラグインでエラーが発生している可能性があると判断できます。
たとえば、
wp-content/plugins/○○○/○○○.php
のように表示されていれば、plugins の次に書かれているフォルダ名が、原因を調べる手がかりになります。
今回確認したところ、バックアップデータの中に含まれていた古いプラグインの一つでPHPエラーが発生していました。
つまり、All-in-One WP Migrationの復元処理そのものが止まっていたというより、復元されたWordPressが古いプラグインを読み込んだ際にエラーが発生していたと考えられます。
エラー文は全部理解できなくても大丈夫
PHPエラーを見ると、初心者の方にはかなり難しく感じると思います。
すべての意味を理解する必要はありません。
まずは、
wp-contentplugins- プラグインらしいフォルダ名
.php- 行番号
などが表示されていないか確認してみましょう。
どのファイルでエラーが発生しているのか分かるだけでも、原因を絞り込む手がかりになります。
5.ローカル環境で原因プラグインを停止する
原因となっているプラグインが確認できたため、ローカル環境のWordPressファイルを開きます。
WordPressのプラグインは、
wp-content/plugins/
の中に保存されています。
今回はWordPress管理画面から正常に操作できる状態ではなかったため、ファイル側から原因プラグインを停止しました。
プラグインフォルダの名前を変更する
wp-content/plugins/
を開き、原因となっているプラグインのフォルダを確認します。
そのフォルダ名を一時的に変更します。
たとえば、
plugin-name
というフォルダであれば、
plugin-name-stop
などに変更します。
WordPressは元のフォルダを見つけられなくなるため、そのプラグインが読み込まれない状態になります。
今回も、この方法でエラーの原因となっていたプラグインを一時的に停止しました。

※プラグインフォルダを変更すると、そのプラグインの機能が利用できなくなります。原因となっているプラグインを確認したうえで作業してください。
6.Macのターミナルから変更する方法もある
前の項目では、Finderから原因となっているプラグインのフォルダ名を変更しました。
Macでは、Finderを使わずにターミナルからフォルダ名を変更することもできます。
WordPressのプラグインは、ローカル環境によっては、
app/public/wp-content/plugins/
のような場所に保存されています。
※保存場所はローカル環境によって異なります。
ターミナルで対象の plugins フォルダへ移動したあと、mv コマンドを使ってフォルダ名を変更できます。
たとえば、
mv plugin-name plugin-name-stop
のように実行します。
mv はファイルやフォルダを移動するときに使うコマンドですが、同じ場所で名前を変更することで、フォルダ名の変更にも利用できます。
この方法でも、WordPressが元のプラグインフォルダを読み込めなくなるため、プラグインを一時的に停止した状態にできます。
※ plugin-name の部分には、原因となっているプラグインのフォルダ名が入ります。
ターミナル操作に慣れていない場合は、前の項目で紹介したように、Finderからフォルダ名を変更する方法で問題ありません。
7.原因プラグインを停止してローカルサイトを再確認する
原因となっていたプラグインを停止したあと、別のタブでローカルサイトを再度確認しました。
すると、先ほど表示されていたPHPエラーは表示されなくなりましたが、今度は
「localhost へのアクセスが拒否されました」

という HTTP ERROR 403 が表示されました。
Localを再起動したり、一度サイトを停止してから起動し直したりしましたが、この時点では403エラーは解消されませんでした。
そこで、Localの One-click Admin をONにし、ログインするWordPressユーザーを指定してから WP Admin を開きました。
すると、WordPressの管理画面へログインでき、ダッシュボードを表示できる状態になりました。
今回の確認では、原因となっていたプラグインを読み込まない状態にしたことで、最初に表示されていたPHPエラーは解消されていました。
ただし、そのままローカルサイトへアクセスすると403エラーが表示されたため、One-click Adminを利用してWordPress管理画面へ入り、復元されたデータの状態を確認しました。

その後、WordPress管理画面でサイトの状態を確認し、復元されたデータが読み込まれているかをチェックしました。
この時点で、PHPエラーの原因となっていたプラグインの影響は避けられ、少なくともWordPress管理画面から復元後の状態を確認できるところまで進めました。
8.復旧後は古いプラグインをそのまま使わない
WordPressの管理画面へ入れるようになったからといって、原因となった古いプラグインをそのまま元に戻すのはおすすめできません。
まず、
- 現在も必要なプラグインなのか
- 新しいバージョンが提供されているか
- WordPressやPHPに対応しているか
- 同じ機能をWordPress標準機能や別の方法で補えるか
を確認します。
特に、長期間保管していたWordPressのバックアップには、長期間更新されていないプラグインや、現在のWordPress・PHP環境に対応していないプラグインが含まれていることがあります。
復元後は、「元の状態に完全に戻す」ことだけを目的にせず、現在の環境でも安全に利用できる状態か確認することが大切です。
9.古いバックアップを復元する前に確認したいこと
今回のようなトラブルを考えると、古いWordPressバックアップを復元するときは、次の点も確認しておくと安心です。
- バックアップを作成した時期
- WordPressのバージョン
- PHPのバージョン
- 使用していたテーマ
- インストールされているプラグイン
- 古いまま残っているプラグインがないか
- 復元先が本番環境かローカル環境か
特に、古いサイトを確認したいだけの場合は、いきなり本番サーバーへ復元するのではなく、まずローカル環境で状態を確認する方法もあります。
今回もまずローカル環境へ復元したため、本番サイトへ直接影響を与えずに、復元後の状態やエラーの原因を確認できました。
10.復元画面が止まったときに確認する流れ
All-in-One WP Migrationなどでバックアップ復元が途中から進まなくなった場合は、次のような順番で確認すると原因を見つけやすくなります。
1.すぐに復元画面を閉じない
まずは少し待ち、処理が続いているのか、本当に止まっているのか確認します。
2.別のタブでサイトを開く
ローカルサイトやWordPress管理画面を開き、エラーが表示されていないか確認します。
3.エラー文を確認する
wp-content/plugins/ など、原因となっているファイルを判断できる記述がないか確認します。
4.原因プラグインを切り分ける
特定のプラグインでエラーが発生している場合は、ローカル環境で一時的に停止します。
5.サイトを再読み込みする
エラーが解消し、サイトやWordPress管理画面を確認できるか確認します。
このように、「復元が止まった=バックアップが壊れている」ではありません。
WordPress本体やPHPとの互換性、テーマ、プラグインなど、復元後に読み込まれる環境の一部が原因でエラーが発生している可能性もあります。
11.All-in-One WP Migrationの古いバージョンを使えばいいわけではない
今回の記事では、以前から使用していた古いバージョンのAll-in-One WP Migrationを使って、バックアップデータをローカル環境へ復元した事例を紹介しました。
ただし、インポートできるファイル容量を増やす目的で、古いバージョンの利用をおすすめしているわけではありません。
WordPressのプラグインは継続的に更新されており、古いバージョンにはセキュリティや互換性の問題が残っている可能性があります。
現在利用しているWordPressでバックアップやサイト移行を行う場合は、利用しているプラグインの最新仕様や提供されている方法を確認しましょう。
今回のように古い環境を復元する必要がある場合でも、本番サイトではなくローカル環境などで状態を確認してから対応する方が安全です。
まとめ|バックアップ復元が止まったら別タブでエラーも確認する
WordPressのバックアップ復元が途中で止まった場合、バックアップデータやAll-in-One WP Migrationだけが原因とは限りません。
今回の事例では、
All-in-One WP Migrationでローカル環境へ復元
↓
「ブログの準備を完了しました。」から進まなくなる
↓
別のタブでローカルサイトを確認
↓
PHPエラーを確認
↓
エラー文から原因プラグインを特定
↓
ローカル環境でプラグインを停止
↓
PHPエラーは解消したが403エラーが表示
↓
One-click AdminからWordPress管理画面へアクセス
↓
ダッシュボードを確認
という流れでした。
復元画面にエラーが表示されていなくても、別のタブでサイトを開くと原因を確認できる場合があります。
また、長期間保管していたバックアップには、現在のWordPressやPHPでは正常に動作しない古いプラグインが含まれていることもあります。
古いWordPressサイトを復元するときは、いきなり本番環境へ戻すのではなく、まずローカル環境で状態を確認し、問題がないか確認してから対応する方法もあります。
