WordPress本番サイトをローカル環境で復元する方法（PHPのバージョンを合わせる）

WordPressで作成されたサイトのデータを、ローカル（または他のドメイン）に再現するのはカンタンです。

「Updraftplus」というプラグインを使えば、メディアやプラグインなどを含めたすべてのデータをバックアップしてくれます。

そして、ローカルに構築したWordPressにも同じく「Updraftplus」をインストールして復元するだけで他の環境にサイトを移行することが可能です。

ただ、本番環境とローカルでWordPressのバージョンが違ったり、PHPのバージョンが違ったりすることで、移行後に正しく動作しないなんてこともあるので、そういった点に注意する必要があります。

今回は作業の中で、そういった操作が必要になったため、備忘として記録を残しておきます。

同じような操作を初めて行う方や慣れていない方の参考になればと思います。

行った手順

1. DockerでローカルWordPress環境を構築しました

PHPのバージョンが異なる

元々DockerでWordPress環境は用意してあり、「 wordpress:latest 」イメージを使用していました。

これは、WordPressの公式Dockerイメージの中で「最新安定版」を自動的に取得する設定です。

しかし、かなり前に構築した環境だったために、復元元の本番環境とPHPのバージョンが異なっているという警告が表示されました。

本番と復元先でPHPのバージョンが異なる場合の対処方法

そのため、本番環境と合わせるために明示的に php8.2-apache を指定するようにしました。

  wordpress:
    image: wordpress:php8.2-apache

PHPのバージョンが異なると、次のような問題が発生する可能性があります：

• テーマやプラグインが正しく動作しない
• 警告やエラー（たとえば Deprecated や Fatal Error）が発生する
• セキュリティや互換性の問題が発生する可能性がある

一般的には、本番環境と同じ、あるいはより新しいPHPバージョンに合わせるほうが安全で推奨されます。

なお、「新しいPHPバージョン → 古いPHPバージョン」へ戻す場合は、対応していないコードが原因で動作しなくなることがあるため、十分な注意が必要です。

Dockerの設定変更内容は以下のとおりです（再掲）

wordpress:
  image: wordpress:php8.2-apache

その後、次のコマンドで再起動を行いました。

docker compose down
docker compose up -d

• down は既存のコンテナを停止・削除するために実行します。
• up -d は新しいイメージに基づいて再構築・バックグラウンドで起動するために使用します。
• Dockerでは、image を変更しただけではコンテナの中身が自動的に更新されないため、一度 down してから up -d する必要があります。

2. UpdraftPlusによる復元作業を実施しました

WordPressの管理画面にログインし、UpdraftPlusを使って本番サイトのバックアップを復元しました。

php8.2に合わせたことで、PHPのバージョンに関する警告は表示されなくなり、問題なく復元が完了しました。

作業中に発生したトラブルと対処方法

トラブル①：docker compose down 実行後にDBが初期化されてしまった

• 原因：docker-compose.yml に volumes: の記述がなく、down でコンテナを削除した際にMySQLのデータも消えてしまったようです。
• 対処方法：以下のように volumes: を追加し、データベースの永続化を実装しました。
  ※データベースの永続化のメリット・デメリットは後述

volumes:
  - db_data:/var/lib/mysql

volumes:
  db_data:

この記述をする前の動きとしては、

1. docker compose down
   → コンテナは完全に削除（ただし -v を付けなければボリュームは残る）
2. docker compose up -d
   → volumes: が未定義だったため、既存のボリュームと接続されず、新しい空のボリュームが自動作成された

つまり、downで箱（コンテナ）を壊し、upで新しい箱を作ったが、中身の保存場所が変わってしまったという状態。

そのため、それまでにあったWordPress環境やデータベースが見られなくなってしまった。

ボリューム db_data について

最下部の volumes: セクションで db_data を定義することで、MySQLのデータを保存するボリューム（外部ストレージのようなもの）を作っています。

これがあることで、コンテナを停止・再起動してもデータベースの中身が保持されます。

ということで試してみました↓↓↓

検証結果

１．再度、down でコンテナを停止・削除してから、up -d でコンテナ再構築。（volumes:の記載あり）
※この操作でMySQLのデータを保存するボリュームが作成される。
※ただし、Docker内（仮想環境）に作成されるので、Finderからは見えない。

２．WordPressの「ようこそ」が表示され、WordPressインストールし直し。

３．インストール後は、データが空っぽな状態。Updraftplusで改めて復元。

４．再度、down でコンテナを停止・削除してから、up -d でコンテナ再構築。

結果、WordPressの再インストールなしで、直前の状態から始められました。

トラブル②：WordPressで「データベース接続確立エラー」が表示された

• 原因：MySQLが初期化されていたことと、WordPressが以前の wp-config.php を読み込んでいたことによるものです。
• 対処方法：public_html フォルダを一度空にして、WordPressの初期インストール画面から再構築を行いました。

運用時の注意点と学び

データベースは常に消える可能性がある前提で運用する

• データを保持したい場合は、volumes: による永続化設定を忘れないようにする。

逆に、ボリュームを消したい場合は、

• docker compose down に -v オプションを付ける

docker compose down -v

補足：「ボリュームごと削除」には注意

Dockerにおける「ボリューム」は、データベースの中身（投稿、設定、ユーザーなど）を保存している実体です。

通常の「 docker compose down 」ではコンテナ（アプリの箱）だけが削除されますが、「-v 」オプションを付けるとその中の「データ（ボリューム）」まで一緒に消えてしまいます。

そのため、誤って「 -v 」を付けたまま実行すると、保存していたWordPressのデータベースが完全に初期化されてしまうリスクがあります。

学習環境ではやり直しで済みますが、本番データや作り込んだ検証環境では大きな損失になります。

ボリュームを削除してリセットしたい場合は、バックアップを取った上で意図的に「 -v 」を使うようにしましょう。

補足：データベース永続化のメリットとデメリット

メリット：

• docker compose down や再起動をしてもデータベースの中身が保持されるため、意図せずデータが消えることがありません。
• 本番に近い継続的な検証が可能になり、作業効率が向上します。
• 定期バックアップと組み合わせることで安全性が高まります。

デメリット：

• クリーンな状態でやり直したい場合に手間がかかります（ボリュームを明示的に削除する必要あり）。
• データベース構成が古いまま残ると、意図しない挙動が起きることがあります。
• ホストマシン上にデータが残り続けるため、ストレージを圧迫することもあります。

ローカル環境をどう活用するか

ローカル環境を構築したら、その使い途としては以下のようなものがあります。

① 本番反映前の検証環境として使う

使い方：

• 本番のバックアップ（UpdraftPlus など）をローカルに復元
• プラグインやテーマのアップデート前に動作確認
• CSSやPHPの修正を事前にチェック

メリット：

• 本番にデプロイするよりも確認が早い
• 本番での不具合を未然に防げる
• 安心して改修作業ができる

② 新機能の開発・テスト

使い方：

• 新しいカスタム投稿タイプ、ショートコード、テーマ機能などを追加
• 本番と同じデータがあるから挙動の再現性が高い

メリット：

• 「動くと思ったのに動かない…」を減らせる
• 複数人での共同開発にも役立つ（Git連携＋ローカル開発）

③ 本番環境のトラブル再現・原因調査

使い方：

• 本番で発生したエラーを、ローカル環境で再現して検証
• wp-config.php の設定を一時的に変えて詳細ログを出力

メリット：

• 安全に試行錯誤できる
• 本番に影響を与えないので安心

④ WordPressの学習やスキルアップにも最適

使い方：

• テーマ自作やプラグイン開発の練習用
• データベース構造の理解にも役立つ（phpMyAdmin付き）

メリット：

• 失敗してもやり直せる
• サンドボックス環境として自由度が高い

注意点と運用のコツ