WordPressの引っ越し(データ移行編)

2022年5月29日

別の記事で、レンタルサーバを引っ越ししましたと、お話しましたがその時の引っ越しってどうやったの?とネットを探せばたくさんある記事なので、目新しいことは少ないですが、備忘も兼ねて今回は書いていきたいと思います。私がやったことなので、おま環問題などもあるのであくまでも参考として優しい気持ちで読んでもらえるとありがたいです。

今回やったこと、諦めたこと

今回引っ越しをする上でやったことと諦めたことをまずはまとめて行きたいと思います。
今回は、ブログサイト自体を再構築して記事単位で引っ越ししたり、サイト構成を見直すという、全面リニューアルではなく、新しいWebサーバにサイトをまるっと引っ越すことにしました。
Q太郎のサイトはWordPress本体、WordPressテーマの「Luxeritas 」(いつも使わせていただき、ありがとう御座います!)、いくつかのプラグインという非常にシンプルな構成なので、引っ越すのに非常に苦労するようなものはありませんでした。

引っ越し自体はあまり、こだわらなければきっとうまく行くのだろうなという感覚はをネットで情報を集める中でなんとなくわかってきましたが、以下は諦めました。

<アクセス履歴や統計情報を最新の状態で持っていくこと>
これに関しては諦めました。確かに引っ越し元サーバは、こんな野良サイトですがありがたいことに一日に数十件くらいのアクセスと、検索エンジンのアクセスがあります。
仕事であればそこもアクセス履歴を漏れずに移行したいようなニーズもあるかもしれませんが、今回はそこまで必要ないと考え割り切りでバックアップ取得後の履歴は移行対象から外しました。

<サーバ証明書の移行>
ロリポップ先生と契約しているプランでは、Let’s Encryptのサーバ証明書をボタン一個で設定してくれる神仕様でしたが、コンテンツフォルダ内を軽く見た(間違ってるかも)限りではサーバ証明書ファイルが見つけられませんでした。
そのため、サーバ証明書を新サーバで使い続けることは諦め、今回は新サーバでは新たに証明書を取得しました。

<テーブル名などの日付の除去>
ロリポ先生では、WordPressの複数サイトを単一データベース内で保持できるようにか、テーブル名に作成日付が付与される形になっていました。
もしかしたらそれ以外の意味もあるのかも。頑張ってエディタで置換すればきっと直せると思いますが、労力に見合わないのでやめました。
VPSなのでリソースが許す限りはDBはいくらでも作れるので、WordPress専用DBにしてしまえば、命名規則をわざわざ直さなくてもいいんじゃない?と諦めました。

<サイト停止時間を作ってしまうこと>
今回の引っ越し方法は、引っ越し先である新サーバ上にWordPressのファイルとデータベースを引っ越しして動作確認した上で、このサイトが指すURLを新サーバに切り替え(サイトのDNS情報の更新)れば良いんじゃないと思って始めたのですが、サーバ証明書を取るにあたり問題が起きてしまったのですが、きちんと考えればダウンタイムなしで移行できると思ったのですが、アクセス履歴も諦めているし、そもそも野良サイトを見てくれる方はほとんどすくないので、1-2時間とまっても良いやという結論になりました。Google先生の検索結果でせっかく来てくれた方、見れなかったらごめんなさい。
また、今後VPSなのでたまに再起動とかで見れなくなることはご容赦ください。(SEO的にはNGですね)

引越しのイメージ

ロリポ先生で動いているこのサイトをどうやって引越しをするかということで、以下のイメージで引っ越し作業をやってみました。センスのかけらもないイメージで申し訳ないです。。
このサイトはWordPressの機能だけでできているので、引っ越すにあたり引越前環境の全部をバックアップをとって、そのバックアップを引越し先環境に持っていくことにしました。
ファイル達は、WordPressのプラグインを使ってまるっとバックアップを取り、そのバックアップファイルから、WordPress本体・プラグイン・記事を構成しているファイル達は引越し先環境のWebフォルダに展開する。
WordPressデータベースに関してはデータベース全体をエクスポート(SQL文で書き出し)し、エクスポートファイルを引越先環境のMariaDBにインポート(SQLの実行)を行うことでデータの引越しは出来そうだとあたりをつけてみました。
データ移行後に動作確認を行い、だいたい動くんじゃないか?(業務じゃないから細かいテストケースやテスト実施などはしません笑)とあたりをつけたら最後にドメインを引越し先環境を指すように切り替えを行ってめでたし、めでたし。。(ホントはそんな簡単にはなりませんでしたが。。。)

引っ越し元でやったこと

引っ越し元環境のWordPressのバックアップ

IT土方の職業病というか、体に染み付いた性でいじる前にバックアップを取ることにしました。
定期的にcronでバックアップ処理を動かすような几帳面なことはせずに、WordPpressのバックアップ用プラグインを使って手動で毎回、バージョンアップするときだけとってました。
バックアップ用のプラグインは世の中には色々ありますが、私が使っているものは「BackWPup」というプラグインを入れました。これ手動実行のスケジュール実行もできるやつなんですが、なぜか定期実行は動かしていませんでした。きっと設定するのがめんどかったのでしょう。
対象はWordPressのファイル全部とデータベース(MariaDB)のフルエクスポートとなります。
基本、これがあれば復旧できます。正確には、WordPressフォルダ内の「wp-content」フォルダがあれば戻せるというような話もありますが、WordPressを仕事でいじくり倒すほど熟知していないので、基本はマルっと全部をバックアップしました。
細かいバックアップに関してはココのサイトさんで解説してくれていますのでご参考にいただければと思います。

引っ越し元環境のWordPress環境の最新化

このサイトは私が長らく放置していたためにWordPress環境が古くなっていました。そこでまずはWordPressの最新化を行いました。やったことは何も難しくありません。
た、なぜ最新化したのかというと、引越し先のPHPバージョンがロリポ先生の7.4ではなく8.0であったことから不具合の可能性を減らす意味でも最新化しました。ついでに、引越し後に最新化した場合に環境の設定不良や環境差異なのかの判断がしずらいので、引越し前環境で最新化して問題なく動作していることが確認できれば、引越し先でエラーが発生しても環境固有の問題ということで調査がしやすいからとも考えたためです。
WordPress管理画面のダッシュボード→更新を選択して、本体、プラグインを更新しました。下の画面のやつですが、すでに最新になっているところはごめんなさい。。ただ、管理画面を見たことがある方なら、ああこれかとすぐに分かると思います。



また、テーマに関しては手動でインストールしていたので、ルクセリタスさんのサイトから最新版のテーマ、小テーマ、一応デザインファイルを持って更新しました。これはテーマの新規インストールと同じ手順でやればWordPressがよしなに更新してくれます。
更新後は、いくつかページを開いたり、移動したり、管理画面の編集ページなどでプラグインが壊れていないかの簡単な動作確認をしました。

最後に引っ越し元サーバの全体をバックアップ

今回は、引っ越し元の環境をまるっと新サーバに移すため、最新化が済んだWordPress環境をまるっとバックアップを取ります。やったことは作業前のバックアップと同じで、レンタルサーバ内のWordPressファイル全部とWordPressが使っている管理データベースのフルエクスポートとなります。
BackWPupで作成したバックアップファイルは、レンタルサーバ内のフォルダにあります、BackWPupプラグインの管理画面からブラウザ経由でダウンロードもできます。ただ、ブラウザ経由からのダウンロードはなぜか2回とも途中で失敗して、ファイルが壊れてしまったので、諦めてロリポ先生が提供しているWeb経由のFTPダウンロード画面からダウンロードしました。こちらではうまく行ったため、PHPのダウンロードサイズ上限にでも引っかかったのでしょうかね。

ここまでで、引っ越し元から、バックアップファイルには引っ越しに必要な以下のファイルが含まれています。基本これらがあれば引っ越しすることができます。

WordPressプログラムロリポ上で最新化したWordPress本体、プラグインのプログラム
WordPressコンテンツ今まで書いた記事と挿絵等の画像ファイル
WordPressデータベースWordPressを動かすためのデータベースのフルエクスポート
データベースの全データを書き出したSQL文

引っ越し先でやったこと

引っ越し先の前提条件

引っ越し先サーバの作業前提としては、以下ができている状態であることとしています。これらの細かい設定作業についても追々紹介しますので、参考にしていただければと思います。
WordPressが動くレンタルサーバであれば特段なにか設定する必要はないのですが、VPSの場合はこれらを一つずつ設定する必要があります。これらの細かい設定に関しては別の記事で紹介していこうと思います。

Webサーバが動作することWebサーバが動作することとなると、漠然とした書き方ですが、基本的にWebサーバで指定したWebコンテンツ配置ディレクトリ上にファイルを配置したファイルがクライアントのブラウザから見れる状態と考えてもらって大丈夫です。
SSL等のセキュリティ、バーチャルホストなどの拡張性などは一旦おいておきます。
phpプログラムが動くことphpコマンドが動作するだけではなく、WordPressが必要なphpモジュールもインストールされていることが大事です。
また、Webサーバ上でphpプログラムが動くことも確認して置く必要があります。
よくphp入門サイトなどで扱っているphpinfo関数の実行結果が表示できればモジュール含めて確認できます。
MariaDBが管理者ユーザでログインできることMariaDBはMariaDBの管理者ユーザでログインできる状態であれば大丈夫です。
もちろん他のデータベースがすでにあるインスタンスにおいても問題ありません。

WordPressデータベースの移行

引越し先環境でまずやったことはデータベースの移行です。WordPressはデータベースがあることを前提としたPHPプログラムのため、DBがないとそもそも動かないので、ファイルを先に移行しても、ブラウザにはエラーしか表示されないので、なんにも確認ができないのです。
BackWPupでバックアップしたファイルの中には、データベースのエクスポートファイル(拡張子がSQL)のファイルが入っていると思います。これをMariaDBのインポートコマンドを実行するか、phpMyAdminがある環境であれば、管理画面からデータベースの移行をすれば大丈夫です。

引越先環境には、phpMyAdminは入れていないのでコマンドベースでやっていきました。
まずは、MariaDBに管理者ユーザでログインして、ユーザを作ります。
create user文でユーザを作り、作ったらユーザ情報を確認します。
今回はデータベース名:「tack」、データベースユーザ「tick」を作りました。

# MariaDBにログインする
$mysql -u root -p

#ユーザ名:tick パスワード:XXXXX のユーザを作る。
MariaDB [(none)]> create user 'tick'@'localhost' identified by 'XXXXXX';

#きちんと作成されたか確認
MariaDB [(none)]> select user,host from mysql.user;
+--------+-----------+
| user   | host      |
+--------+-----------+
| root   | 127.0.0.1 |
| root   | ::1       |
| root   | localhost |
| tick   | localhost |     ←ユーザ:tickできてますね。
+--------+-----------+ 
4 rows in set (0.001 sec)

次にデータベースを作成し、データベースに対して、先程作成したユーザの実行権限を付与します。

#データベース名:tack を作成する
MariaDB [(none)]> create database tack;
Query OK, 1 row affected (0.001 sec)

#作成されたことを確認する
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| tack             |   ←データベース「tack」できていますね。
+--------------------+
4 rows in set (0.001 sec)

#ユーザ:tickに対して、データベース:tackのフルコントロールを付与します。
MariaDB [(none)]> grant all on tack.* to tick@'localhost';
Query OK, 0 rows affected (0.001 sec)

#権限を即時反映します。
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)

#権限が設定されたことを確認します。
MariaDB [(none)]> show grants for tick@localhost;
+---------------------------------------------------------------------------------------------------------------+
| Grants for tick@localhost                                                                                   |
+---------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `tick`@`localhost` IDENTIFIED BY PASSWORD 'XXXXXXXXXXXXX' |
| GRANT ALL PRIVILEGES ON `tack`.* TO `tick`@`localhost`             |   ←できてますね。
+---------------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)

#MariaDBから抜けます。
MariaDB [(none)]> exit

データベースの準備が整ったら、BackWPupで取得した引越し元サーバのフルエクスポートファイルを引越先環境のサーバ上の作業フォルダにSFTPを使ってアップロードし、ファイルを展開します。

# /tmp/workにファイルをSFTPでアップロードし、展開します。
$ cd /tmp/work
$ ls
ticktack.tar.gz  ←これがバックアップファイルです。
#バックアップファイルを解凍します。
$ tar xvzf ticktack.tar.gz
$ ls
ticktack.sql.gz      ←これがバックアップファイルです。他にはWordPressのファイルが大量にあります。
#エクスポートファイルを解凍します。
$gzip ticktack.sql.gz   
$ ls
ticktack.sql      ←解凍できました。

これでWordPressがインポートをしていきます。インポート自体は以下のコマンド一発です。
ticktack.sqlはBackWPupで取得した引越し元サーバのフルエクスポートファイルをSFTP等でサーバの適当なディレクトリに配置し、そのファイルに対して以下のコマンドを実行するだけです。
ファイルサイズによりますが、インポート自体は10秒もかからずで終わります。(私の環境では10MB程度でした。)

# ユーザ:tick でデータベース:tackに、バックアップファイル:ticktack.sqlをインポートする
$mysql -u tick -p tack < ticktack.sql

私の環境では後にちょっとハマったので、備忘のために書いておきます。
WordPressデータベースには、自分のサイトのURL情報を持っています。WordPress管理画面の「設定」→「一般」のところにあるやつです。
このURLを動作確認中は変えておかないと、引越先環境がSSL化する前だったりすると、動かなくなってしまうので、インポート後でもデータベースに格納されたデータをupdate文で更新すればよいのですが、インポート前にデータを直しておいた方が楽なのでここに書いておきます。

#バックアップファイルはSQL文が書いてあるテキストファイルなのでエディタで開けます。
#以下の2つが変えていないと後々問題になるやつです。siteurlとhome
INSERT INTO `wp_options` (`option_id`, `option_name`, `option_value`, `autoload`) VALUES 
(1, 'siteurl', 'https://www.ticktack.biz/', 'yes'),
(2, 'home', 'https://www.ticktack.biz/', 'yes'),

ここまででデータベースの移行は完了です。簡単ですよね。

ファイル(WordPress本体、プラグイン、記事)の移行

ファイルの移行は単純です。バックアップファイルをWebサーバのコンテンツフォルダにまるっと格納してあげtればOKです。以下は完全に私の環境なのであくまでも参考ですが、Webサーバの公開用ディレクトリとWebサーバの実行ユーザは以下としました。レンタルサーバでは割り当てられたディレクトリ情報などは、契約時にもらえると思います。実際は、レンタルサーバだとサーバへのログインユーザでログインした場所が公開用ディレクトリになっていると思うのでその場合は、バックアップファイルを解凍してアップロードするだけだと思います。所有者もアップロード時に自動的に変わると思います。

Webサーバの公開用ディレクトリ/var/www/html/ticktack
Webサーバの実行ユーザwww

今回私は、少し前の作業で/tmp/workにバックアップファイルをアップロード、解凍しているため、見せたくないデータベースのフルエクスポートファイルを削除したら、残りのファイル全部を公開用ディレクトリに移動し、ファイルの所有者をWebサーバの実行ユーザに変更しました。

#WordPressのバックアップファイルを解凍したフォルダに移動します。
$cd /tmp/work
#データベースのフルエクスポートファイルは見せたくないので削除します。
#rm ticktack.sql
#WordPressのバックアップファイル全体をWebサーバのディレクトリに移動します。
$mv  * /var/www/html/ticktack
#ファイルがあることを確認します。
$ ls /var/www/html/ticktack
#所有者をWebサーバの実行ユーザに変更します。
$ chown -R www:www /var/www/html/ticktack

WordPressの設定変更

ファイルを配置するだけで移行は終わりと言いましたが、ごめんなさい。WordPressが動くための設定を修正する必要があります。引越前環境と引越先環境ではデータベース名、データベースのユーザが変わっている場合もあるので、それらを設定しているファイル「wp-config.php」の以下を直していきます。

#データベース移行時に作ったデータベース:tack に修正
/** WordPress のためのデータベース名 */
define('DB_NAME', 'tack');

#データベース移行時に作ったユーザ:tickのユーザ名に修正
/** MySQL データベースのユーザー名 */
define('DB_USER', 'tick');

#データベース移行時に作ったユーザ:tickのパスワードに修正
/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'XXXXXX');

# Webサーバと同じサーバでWordPressデータベース(MariaDB)が動いているのでlocalhostに修正
/** MySQL のホスト名 */  
define('DB_HOST', 'localhost');

動作確認

それでは、WordPressのデータ移行は完了しましたので、WordPressが動くか確認してみます。
ブラウザで管理画面にアクセスしてみましょう!この時点だとまだSSL化もドメインの切り替えもやっていないので、IPアドレスでアクセスしてみます。なんとか表示できましたね。

管理画面はどうでしょう?表示できました。良かったです!

おわりに

この時点では、まだ移行は道半ばです。暗号化(SSL)もできていないし、ドメインの切り替えもまだ終わっていないので、IPアドレスでしかアクセスできません。
実は、IPアドレスで表示させるまでにもこんなに簡単にはうまく行っておらず、最初のアクセス時は真っ白い画面(データベース接続エラー)やら、WordPressが保持しているURL情報の設定漏れ(データベース内のsiteurlとhomeの登録データをupdate文で直したり)、Webサーバ自体の設定不良を直したりと紆余曲折ありました。。
これらのシステム移行に関しては、分量も多くなってきたので、また次回にまとめてみみようと思います。

Linux,Tips

Posted by Qtaro