この記事を読むのに必要な時間は約 11 分です。
数年ほどブログから遠ざかっていましたが、久しぶりにブログを書こうとWordPressの管理画面を開きました。管理画面では利用しているPHPのバージョンが古いのでバージョンアップをしてくださいという通知が出ていました。
せっかく再開するのでベース部分は更新しようかなと更新を始めたのが失敗でした。。最終的には元々のサーバー上のサイトは全く動かなくなり、新たにサーバー追加してそこに完全移植する形でやっとこさ復活できたので今後似たようなことがあった時にどのような対応が必要かを残すために記述します。
※この記事自体は新しい環境で記述しています。
引越し前後の変化
項目 | Before | After |
OS | Debine 10 | Debine 11 |
PHP | 7系 | 8.1 |
MySQL | 5系 | 8系 |
WordPress | ?? | 6.8.2 (最新) |
全てを最新にしたわけではありませんが、簡単に更新ができる部分を更新して対応しています。最初はPHPのバージョンだけアップデートするつもりでしたが、OS自体も古かったためOSもアップデートをすることにし、OSアップデート中にMySQLも新しくすることにしたため全体的にアップデートをすることになりました。
大失敗のアップデート
私のWordPress環境はGCPのGCE上にワンクリックでデプロイできるやり方で作成していました。元々はレンタルサーバーを利用していましたがアカウントを停止されたため過去に移行をしています。

今回はこの環境に対してSSHで接続しDebineのアップデートをしていました。アップデート方法はClaudeに質問して言われた通りの手順を実施することで無事Debine 10 から 12にアップデート自体を行うことができましたが、その時点でサイトにアクセスができない状態になっていました。
※Debineのアップデート自体は細かいところは覚えていませんが /etc/apt/sources.list
を更新してインストールを行うというのを複数回行って完了しました。

どうやらDebineの更新作業でMySQLのバージョンが上がったのとDebine 12だとMySQLではなくMariaDBがデフォルトになるなど色々と要因がありうまくDBと繋がらない状態になっていました。
改善しようとこれまたClaudeやChat GPTに質問しながら対応を進めていましたが、どうにもMySQLのインストールが上手くいかず結局環境を更新することを諦めることにしました。
再度インスタンスを作り直してバックアップからの復旧
上記作業を行う前にファイルとDBはバックアップを取得していたのでベースのWordPress環境を新たに最新の状態で作り直してバックアップのデータを入れることで復元する方向に進めることにしました。
バックアップ自体は大きくは以下の2つあれば事足ります。
- /var/www/html フォルダ以下一式
- データベースのバックアップ (SQLファイル)
前者は作業前にSSHで接続し、ローカルにファイルを一式落としており、後者のSQLに関してはwpコマンドでバックアップ取得していたのでそれを利用することにしました。
データベースのバックアップはWP CLIの以下のコマンドで取得しています。
wp db export
※コマンドの詳細に関しては以下参考にしてください。
GCP上でWordPressの環境を作成する場合GKEとGCEとCloud Runの3通りのやり方が大きくはありますが、今回は前回と同様にClickだけで環境が作成可能なGCEで作成します。

内容を確認するとDebineは最新ではないですが、PHPやMySQLなどが8系に上がるためこちらで作ることにしました。

設定は基本はデフォルトでマシンタイプだけ e2-micro
を選択して月額料金を抑えるようにしています。
e2-microでストレージが20GB程度だと大体月額1,500円弱ぐらいのようです。

これで環境が立ち上がったのでファイルとデータベースをバックアップから復旧していきます。
データベースの復旧
まずはデータベースから入れていきます。作成した環境に対してSSHで接続し、バックアップしておいたデータベースのSQLファイルをアップロードしてからデータベースへインポートを行います。
最初はphpMyAdminの画面からファイルをアップロードしてインポートしようとしましたが、画面上からだと2MBまでしか対応していないようなのでサーバー上からmysqlコマンでインポートをすることにしました。

コマンドは以下の通りです。mysql自体は先ほど作成した環境に最初から入っているのでこのコマンドを実行すると通ります。mysqlのバージョンが変わっているのでそのままでは通らないかと思いましたが、意外とそのまま通りました。
mysql -u username -p database_name < dump_file.sql
※SQLファイル内に旧サーバーのIPアドレスが直接書かれていたりする場合はそのままインポートしても上手く動かないので一括で置換してから入れる必要があります。自分は一度それでインポート後に上手く動かず置換してから再インポートをしています。
SQLインポート後にWordPress管理画面を開こうとすると、現行サイトのドメインにリダイレクトされてしまいました。調べてみるとWordPressの wp_options
で保持しているsiteUrlやhomeが影響していそうだったのでここは一時的に立ち上げたサーバーのIPアドレスに置き換えて作業を続けます。

ファイルの復旧
現行サイトからとっておいた /var/www/html
をそのまま新しいサーバーへとコピーします。この時の注意点としてはphpmyadminとwp-config.php
を除外してコピーすることです。phpmyadminはバージョンが新しくなっているため古いものを入れてしまうとログインができなくなります。古いものを入れてしまっても新しいものをさらに入れ直すことで動くので最終的には問題ないですが、作業の手間を省くためには除外が必要です。私は何も気にせず全部コピーしてしまったので後からphpmyadminを入れ直してwp-config.phpの設定を上書きしています。
phpmyadminの入れ直しは以下が参考になります。(この記事の中のwgetとunzip部分のみ対応)
wp-config.php
はDBへの接続情報などが記述されており、ここも新旧で値が異なるのでこれも復旧対象外となります。
復旧が完了した後にサイトを開くと以下のような表示で上手く表示されませんでした。

トラブルシューティングを確認したところプラグインを全て無効にすることで解消することがありそうなのでその対応を行いました。DBを変更する方法とフォルダ名を変更する方法の2がありますが、私は後者のフォルダ名を変更する方法でプラグインを無効化しました。

プラグイン無効化後はサイトが表示されるようになったのでこれで大枠の復旧が完了した状態となりました。
その他設定作業
データベースとファイルの復旧が完了したので他にドメインや無効化したプラグインの有効化など細かい作業を行っていきます。実際に対応したので以下の作業になります。
- DNSの設定
- SSL証明書の設定
- プラグインのチェックと有効化
- サイト設定の変更
- ファイルの権限変更
それぞれ順に対応した内容を記述していきます。
DNSの設定
DNSは元々のサーバーを向いていたので、新しいサーバーへと向けてあげます。Cloud DNSで管理していたのでCloud DNS上で対象のドメインのAレコードを更新しています。
SSL証明書の設定
SSLの証明書も前回同様certbotを用いてLet’s Encryptで作成します。前回はcertbotの公式サイト上のコマンドでうまくいきましたが、今回はうまくいかなかったので別のサイトを参考にして対応しました。
具体的には以下のコマンドで設定が完了しました。
sudo apt-get install python3-certbot-apache -y
sudo certbot -d takeiho.com -d www.takeiho.com
プラグインのチェックと有効化
サイト復旧手順でpluginsをリネームして全て無効化したのでそれを戻していきます。リネームで再度戻すとプラグインは全て無効化された状態になっているため、必要なものだけを再度1つずつ有効化しサイトが動くかをチェックしていきます。
プラグインは詳細を表示することで最新バージョンで互換性があるかの確認ができるので対応しているものの中で必要なものだけを有効化していきます。
サイト設定の変更
最初にデータベースをインポートした後に変更したドメイン部分を元に戻します。
ファイルの権限変更
一部のプラグインはファイルの変更権限が必要になります。そのため、権限をつけてあげる必要があります。具体的には以下のコマンドで設定が可能です。
sudo chown -R www-data:www-data /var/www
まとめ
今回サーバーを新しい状態にした際の備忘録を記述しました。かなり詰まって遠回りをしましたが、なんとか復旧できたので今後は少しずつサイトデザインの変更や記事の更新をやっていきたいと思います。