サーバマシンの入れ替えに伴って、サーバOSが従来のCentOS 5.xからCentOS 6.xにアップグレードされました。
アップグレードと言っても、OSは新規にインストールしなおしたものなので（プラットフォームごとの変更だったので）、これに伴ってWordPressを入れ直すことに。
さて、WordPressのバックアップ・リストアの情報を探すと、例えばこことかこことかこことか色々ヒットしますが、これらはどれもレンタルサーバを前提とし、かつ一度WordPressをインストールしてから環境を復元する、という二重の手順になっています。
でもうちはせっかくの自前サーバですから、もっと簡単に、
- mysqlでデータベースのバックアップを作成
- コンテンツはBLOGのディレクトリを丸ごとコピー
- mysqlでデータベースを復元
- 所定のディレクトリにBLOGのディレクトリを再度コピー
という手順でリストアできるんじゃないかな・・・と仮説を立ててみました。
結論から言うと、小さな問題は発生しましたが、とりあえずは元どおりになった（みたいにみえます）。
せっかくなので、以下にその手順をば記しておきます。
手順１：mysqlでデータベースのバックアップを作成
これはここでも紹介した通りですが、念のため。
# mysqldump -u root -p DB_name > dump.sql
とすることで、dump.sqlというバックアップ（全データベースのバックアップ）が取得できます。
手順２：コンテンツはBLOGのディレクトリを丸ごとコピー
これはいいですね（笑）
普通にディレクトリをコピーするだけです。GUIならマウスで、CUIならcp -rで。
手順３：mysqlでデータベースを復元
これは少し手間取りました。
というのも、単純にコマンドでデータベースを戻すだけではうまくいかなかったからです。
具体的には、データベースのリストアに先立って、BLOG用のデータベースを（再度）作成し、さらにBLOGのデータベースを作成したユーザを作成し、権限付与しなければなりませんでした。
というわけで、まずはデータベースの作成から（復旧するにあたって、データベースのガワを作っておくというイメージ？）。
# mysql -u root -p
Enter password:
mysql> CREATE DATABASE `db_name`;
Query OK, 1 row affected
mysql> exit
Bye
ここで’db_name’となっているところに、クオーテーション抜きでもともとBLOG用に作成してあったデータベースを作成しておきます。
これをしないと、dump.sqlにあるBLOG用のデータベースを「復旧」できないということのようですね（データベースの名前が違っていたら復旧するデータベースとはなりませんものね）。
念のためこの時点で
mysql> show databases;
して、BLOG用のデータベースが（以前のそれと同名で）作成されていればひとまずはOKです。
そうしたら（もしかしたら必要ないのかもしれませんが）、データベース名と同名でユーザを作成しておきます。
mysql> GRANT ALL ON ‘db_name’.* TO ‘db_name’@localhost IDENTIFIED BY ‘db_name’s password’;
Query OK, 0 rows affected (0.10 sec)
mysql> grant all on db_name.* to ‘db_name’@’localhost’ identified by ‘db_name’s password’;
（mysql 5.7ではクオーテーションの有無に変更が生じている？）
これでBLOG用のデータベースに同名のユーザがフルアクセスできるようになりました。
ここまで来て初めてバックアップしたデータベースを元に戻します。
# mysql -u root -p < dumpfile.sql
# mysql -u root -p db_name < dumpfile.sql
（データベース名を入れずにリストアを試みると、
ERROR 1046 (3D000) at line 22: No database selected
というエラーが返されました。
そのため、コマンドにてdumpファイルをリストアするデータベースを指定するようにします）
これで全てのデータベース（つまりBLOG用以外のデータベースも含めたすべてのデータベース）がリストアされます。
手順４：所定のディレクトリにBLOGのディレクトリを再度コピー
これも簡単ですね。わけがわからなくならないように、前と同じパスに戻しておきました。
これで理論上は前と同じ環境が整っているはず。httpsdが起動していることを確認して、BLOGにアクセスし、表示されればOKです。
もし「データベース接続確立エラー」などがでるようでしたら、WordPressをデバッグモードにして何のエラーが出ているのかを確認します。デバッグモードにするには、wp-config.phpを書き換えます。
define('WP_DEBUG', false);
という行があるので、このfalseをtrueに書き換えます。
※デバッグを終えたら、ここは元の通りfalseに書き戻しておきます。
これでエラーの内容を確認できるのですが、データベース接続確立エラーの場合、大抵はwp-config.phpのデータベースに関する4つの項目に間違いがあることが殆どです。
// ** MySQL 設定 – こちらの情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define(‘DB_NAME’, ‘db_name’);
/** MySQL データベースのユーザー名 */
define(‘DB_USER’, ‘db_name’);
/** MySQL データベースのパスワード */
define(‘DB_PASSWORD’, ‘db_password’);
/** MySQL のホスト名 */
define(‘DB_HOST’, ‘localhost’);
wp-config.phpを開くとすぐに見つかります。
僕も今回散々このデータベース接続確立エラーが表示されましたが、結局のところその原因はこのうちの一番最後のMySQLのホスト名に間違いがあったというものでした。
・・・でも、wp-config.phpはディレクトリごとバックアップを取っているのだから、以前のそれですし、同じ設定にしているのだからエラーが出るはずはないんですがねぇ・・・。
それでも結論から言うと、ここをホスト名ではなくそのままlocalhostにすることで解決したという・・・(^_^;;
ま、いずれにしてもここを適宜修正することでWordPressは問題なく（もちろんプラグインも含めて）元どおり稼働させることができました。
最悪の場合は、WordPressを新規に入れて、UpdraftPlusでリストアすればいいか、というセカンドプランがあったので比較的気軽に実行することができましたが、やり方としてはたぶんこのほうがスマートなんじゃないかな？
（っていうか、なんか「自分の力で復旧させた！」という気分が味わえるような気がしません？ 笑）
このやり方はレンタルサーバとかだとできないのかもしれませんが、まぁこういうやり方もあった、ということで、どなたかの参考になれば幸いです。
