前回までの手順で、移行先サーバでWordpressが起動するようになりました。本稿では、Wordpressのコンテンツの移行を行います。
バックアップの取得
ここから先に進む前に、一度バックアップを取っておきましょう。バックアップを取得しておけば、データの移行に失敗したとしてもいつでも開始時点に戻ることができます。特にツールを利用すると、何が悪くてデータ移行が失敗したのか判断できない、でも元の状態に戻すこともできないということが発生します。
また、この先はWordpressの初期設定が可能な状態のサーバを、誰でもアクセス可能な状態で作業を進めることになるため、不正アクセスの可能性も否定できません。万一そのような事態があっても、”きれいな”イメージがあればゼロからやり直す手間を省くことができます。
VPSの動作イメージのバックアップは、Conoha VPSが提供する機能で実施することができます。sudo poweroffなどで一度サーバの電源を落としてからConohaのコントロールパネルを開くと、”イメージ保存”というメニューが有効になるので、こちらでバックアップを取得しましょう。
バックアップされたイメージはVPSとして契約したストレージ容量とは別に50GBまで利用可能なようなので、うまく活用しましょう。なお、利用実績がないイメージは90日で削除されるようですが、セットアップ中に起点に戻るという意味では十分だと思います。
移行準備
具体的な移行作業に入る前に、念のため現時点でのWordpressのホームディレクトリを丸ごと固めて、ローカルにダウンロードしておきます。移行しそこなったデータがあっても、これがあれば救済可能です。試してみたら、388MBのファイルになりました。
% sudo tar -cvf /home/ryu/starplatinum_20210226.tar.gz /var/www/vhosts/starplatinum/*
% ls -lah /home/ryu/starplatinum_20210226.tar
-rw-r--r-- 1 root root 388M 2月 26 13:24 2021 /home/ryu/starplatinum_20210226.tar移行手段の検討
Wordpressの移行には様々な手段があります。最近もっともよく見かけるのは、All-in-One WP Migrationというプラグインを利用した移行手順なので、まずはこちらを試してみます。
プラグインの利用方法については様々なサイトで解説されていますし、特に難しい点もないのでここでは説明を割愛します。まずはスパムコメントと投稿リビジョンをエクスポート対象から外してみましたが、それでもエクスポートされたファイルのサイズが686MBにもなってしまいました。追加でメディアライブラリを外しましたが、まだ596MBもあります。
巨大データの捜索と削除
自分のサイトのサイズから考えても、移行すべきファイルがこれほどのサイズとはちょっと考えにくいので、移行対象となるデータを調査してみます。まずはWordpressが導入されているディレクトリの容量確認します。
% pwd
/var/www/vhosts/starplatinum
% ls -lah
合計 195M
drwxr-xr-x 9 nginx nginx 4.0K 2月 27 15:51 2021 .
drwxr-xr-x 4 nginx nginx 4.0K 2月 8 13:08 2015 ..
-rw-r--r-- 1 nginx nginx 236 9月 27 23:22 2015 .htaccess
-rw-r--r-- 1 nginx nginx 194M 2月 26 13:19 2021 ads.txt
(以下略)8行目に注目してください。ads.txtというファイルが194MBもあります。このファイルはバックアップ対象のはずなので、このファイルは削除します。ads.txtはGoogle Adsense = 広告関連のファイルですが、なぜここまで肥大化したのは全く分かりません。これはGoogleからダウンロードできるファイルで、移行後に再度設置しなおせばいいはずですが、念のためgzipで固めてから無関係の場所 (ユーザのホームディレクトリ) に退避しておきました。
続いてデータベースの中身を確認してみます。データベース名とパスワードはwp-config.phpに書かれていますが、管理人の環境ではroot & パスワードなしでそのままログインできました。
% mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1801151
Server version: 5.5.62-38.14 Percona Server (GPL), Release 38.14, Revision 7e0e1cc
Copyright (c) 2009-2018 Percona LLC and/or its affiliates
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| wordpress |
+--------------------+
6 rows in set (0.03 sec)
mysql> use wordpress
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------------------+
| Tables_in_wordpress |
+----------------------------+
| wp_actionscheduler_actions |
| wp_actionscheduler_claims |
| wp_actionscheduler_groups |
| wp_actionscheduler_logs |
| wp_aioseo_notifications |
| wp_aioseo_posts |
| wp_commentmeta |
| wp_comments |
| wp_links |
| wp_lockdowns |
| wp_login_fails |
| wp_ms_snippets |
| wp_options |
| wp_postmeta |
| wp_posts |
| wp_snippets |
| wp_term_relationships |
| wp_term_taxonomy |
| wp_termmeta |
| wp_terms |
| wp_user_login_log |
| wp_usermeta |
| wp_users |
+----------------------------+
23 rows in set (0.00 sec)見た感じ、Wordpress本体が利用するテーブルとは別に、プラグインが独自に作成したテーブルもあるようです。結論から書くと、wp_user_login_logというテーブルに100万件以上のログがたまっていました。これはCrazy Boneというログイン履歴を取得するプラグインが利用するテーブルのようですが、ログの削除をせずに数年間放置していたので、膨大なデータが蓄積されていたようです。
プラグインを削除するとテーブルも削除されるとのことですが、自分の環境ではなぜか削除されなかったようなので、テーブルを手動で削除します。drop後にテーブルの数が一つ減っていることが確認できます。
mysql> select count(*) from wp_user_login_log;
+----------+
| count(*) |
+----------+
| 1132991 |
+----------+
1 row in set (1.26 sec)
mysql> drop table wp_user_login_log;
Query OK, 0 rows affected (0.68 sec)
mysql> show tables;
(snip)
22 rows in set (0.00 sec)ads.txtの削除と wp_user_login_log の削除を行ってから再度All-in-One WP Migrationでバックアップを取得 (スパムコメントと投稿リビジョンは取得しない) したところ、完了まで数十分を要していたバックアップ時間は数秒になり、ファイルサイズは150MBになりました。ファイルはそのままブラウザからローカルにダウンロードできるので、保存しておきます。
移行先のサーバへのインポート
移行元のVPSのバックアップデータが取得できたら、続いて移行先にデータをインポートします。移行先のVPSを起動し、Wordpressのインストール画面に移動し、インストール作業を行います。ここで設定した値はバックアップを復元すると上書きされるので、あまり気にする必要はありません。設定が完了すると一度ログアウトして、作成したユーザでログインすることになります。
無事Wordpressのコントロールパネルにログインできたら、All-in-One WP Migrationをインストールして、インポートを行います。アップロード可能なファイルサイズを超えている、というエラーが出たら、/etc/php/7.4/fpm/php.iniの以下の部分 (690, 844行目付近) を、アップロードしようとしているファイルサイズより大きな数字に修正・上書きしてから、”sudo systemctl restart php7.4-fpm.service” でfpmを再起動、ページをリロードしてから再度実行すれば、うまくいくはずです。
; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
post_max_size = 256M
(中略)
; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 256Mバックアップは大丈夫か？と聞かれますが、大丈夫なのでそのまま先に進みます。無事インポートが完了すると、以下の画面が現れます。
”パーマリンク構造を保存する”をクリックすると、ログイン画面に遷移します。この時点でログインユーザの情報も移行元サイトの情報で上書きされているので注意しましょう。パーマリンクの構造は、移行元サイトと同じ設定を選択しましょう。
移行後先の各種設定
インポートが完了したら、ダッシュボードにある”サイトヘルスステータス”にアクセスします。ここで不足しているとされるモジュールがあったら、追加で導入します。管理人の環境では以下のようになっていたので、
以下のように不足しているとされるモジュールの追加導入を行いました。管理人の環境では、php-imagickの導入時にImageMagic本体とgdも併せて導入されました。
% sudo apt-get install php-curl
% sudo apt-get install php-xml
% sudo apt-get install php-imgick
% sudo apt-get install php-zipこれでモジュールの問題は解決するはずです。代わりにHTTPSが利用できないということが致命的なエラーとして現れますので、続いてHTTPSの利用を可能にするために、Let’s Encryptを利用したサイトのHTTPS化を行います。