以前、Eclipseでbitnami WordPressをローカル環境でデバッグできる開発環境を構築しました。さらに、その環境下で、レンタルサーバーの環境を複製することが出来れば、Wordpressやプラグインの更新、テーマの編集、記事の作成をより安全に行うことが出来ます。恐らく、サーバー上で更新や編集を行って、ログインできなくなったり、サイトの表示がおかしくなったりして、焦ることはかなり減ると思います。今まではこのサーバー上の環境をローカル環境に複製する方法に中々手が付けられずにいました。最近、 Duplicator で、サーバーの環境をローカル環境に移転する方法が分かったので紹介したいと思います。
はじめに
以前、Wordpressの仕組みを理解するため、オリジナルテーマを作ることを思い立ちました。そして、Wordpressのオリジナルテーマを作るため、PHPの開発環境を最初に構築しました。
この時は、とりあえず、オリジナルテーマを作ることが目的で、Wordpressのデバッグが目的ではありませんでした。しかし、他のテーマの動作などを調べるためにデバッグ環境が必要になりました。そこで、Eclipseでbitnami WordPressをローカル環境でデバッグできる開発環境を構築しました。
さらに、ローカル環境下で、レンタルサーバーの環境を複製したいと思うようになりました。これは、Wordpressを使用していて、サーバーの設定変更や、Wordpress本体およびそのプラグインの更新などをすると、稀にサイトにアクセスできなくなることがあったからです。また、テーマの編集を行ったことで、サイトのデザインが崩れてしまったり、予期せぬエラーが出てサイトにアクセスできなかったりする場合もあります。
サイトにアクセスできないとどうなるかというと、場合によっては今までに作成してきた記事を全て失う可能性があります。記事が少なくて広告収入も少ないうちはまだ良いかもしれません。しかし、記事数が増えて、なおかつ広告収入も増えてくると、これまで作成してきた記事を失ったときのダメージは計り知れません。さらに、既存の記事を編集する場合、サーバー側で編集すると、編集し終わるまで更新できません。まぁ、公開状態を非公開に変更すれば良いのかもしれませんが、その間、非公開にされた記事に来る閲覧者が減る可能性があります。
サーバーの環境をローカル環境に複製し、ローカル環境でWordpressやプラグインの更新、テーマの編集、記事の作成や再編集を事前に行えば、サーバー側でこれらの作業をより安全に行うことが出来ます。恐らく、サーバー上で更新や編集を行って、ログインできなくなったり、サイトの表示がおかしくなったりして、焦ることはかなり減るのではないでしょうか。しかし、今まではこのサーバー上の環境をローカル環境に複製する方法に中々手が付けられずにいました。理由としては、プラグインを利用しない場合、複製に必要な手順が私のような初心者には敷居が高いということが挙げられます。
プラグインを利用せずに複製する方法を紹介しているサイトは数多くあります。ただ、サーバーのphpAdminにあるデータベースから複製に必要なテーブルを選択したり、そのテーブルの内容を編集したり、簡単そうに見えて実際に試してみると意外と上手くいきませんでした。そこで、サーバーにあるWordpressの環境をBitnami WordPressに複製できそうなプラグインについて検索したところ、以下のサイトを見つけました。
ただし、ここで紹介されているBitnami WordPressはBitnami WordPress Stackで当サイトで扱ってきたものと異なります。当サイトでは、PHP開発環境としてXAMPPを利用しており、XAMPPにBitnami WordPressを組み込む形でWordpressのデバッグ環境を構築しています。しかし、Bitnami WordPress Stackは、PHP開発環境が異なり、XAMPPがなくても動作します。この点に関しては、初心者がローカル環境でWordpressを扱う場合、ハードルがかなり下がると思います。ただし、開発環境の設定に関する情報が少なく、XAMPPに比べると設定の自由度が低いように思われます。
試しに、EclipseとBitnami WordPress Stackの組み合わせでデバッグ環境を構築できるか試しました。ところが、今までの通りの設定では、ブレークポイントで停止せず、デバッグが出来ませんでした。デバッグが出来る環境にするには、XAMPPにBitnami WordPressをインストールし、そのBitnami WordPressにDuplicatorでデータを移転するしかないようです。Duplicatorを利用した移転方法を紹介するサイトは数多くあり、一見、簡単そうに見えます。しかし、実際に試してみるとかなり厄介で、All-in-One WP Migrationの方が簡単です。
All-in-One WP Migrationは、移転先にWordpressとAll-in-One WP Migrationがインストールされていれば、移転元のデータを移転先のAll-in-One WP Migrationでインポートするだけです。ただ、All-in-One WP Migrationは、データのサイズが510MBを超える場合には有料になります。当サイトの全データをAll-in-One WP Migrationでバックアップすると、510MBを超え、その大半が画像ファイルでした。510MBを超えないようにするために、画像ファイルをバックアップに含めなければ、約420MBになります。このため、画像ファイルを別にダウンロードして、後で移転先に再配置する必要がでてきます。
Duplicatorでバックアップすると、キャッシュなどを除外しても画像ファイルを含めて約260MBになります。また、画像ファイルを含めたバックアップのため、All-in-One WP Migrationのように画像ファイルを後で配置するという作業は必要ありません。しかし、Duplicatorでバックアップを移転先に導入できるようになるまでには数多くのエラーにぶち当たり、幾度となく心が折れそうになりました。それでも、Duplicatorは、原因や対策が分かると案外すんなりと導入でき、バックアップファイルがAll-in-One WP Migrationに比べて軽いです。このため、バックアップファイルがサーバーの容量を圧迫せず、ダウンロードも早いです。Duplicatorを導入するにあたり、色々と問題がありましたが、無事にバックアップデータをBitnami WordPressに複製することが出来ました。そこで、 今回、Duplicatorでサーバーの環境をBitnami WordPressに複製する方法とその際の注意点について、紹介したいと思います。
Duplicator について
Duplicatorは、Wordpressのサイトをバックアップしたり、コピーしたり、移動させたりすることができるプラグインです。このような機能を持つ他のプラグインには、All-in-One WP Migrationが挙げられます。とりあえず、DuplicatorとAll-in-One WP Migrationのどちらも試してみました。というより、最初にDuplicatorでこのサイトのバックアップを作成し、Bitnami WordPressのデバッグ環境にデータを移そうとしたんですよね。ところが、エラーばかりで、上手くデータを移すことが出来なかったんです。そこで、困った挙句にAll-in-One WP Migrationに手を出すことになったというのが実情です。はっきり言って、DuplicatorとAll-in-One WP Migrationではどちらが簡単に扱えるかというと、バックアップデータのサイズが510MBより小さければ、間違いなく、All-in-One WP Migrationでしょう。しかし、データサイズが大きいと、無料で利用する場合は、バックアップするデータを色々と省く必要があります。この点に関しては、Duplicatorもデータサイズによる制限があり、同様だと思います。しかし、同じサイトをバックアップした場合、Duplicatorの方がAll-in-One WP Migrationよりもバックアップファイルのサイズが小さいです。例えば、現時点での当サイトのバックアップファイルを比較してみると、以下の表のようになります。
| 最大構成 |
最小構成 |
|
| Duplicator | 294MB | 261MB |
| All-in-One WP Migration | 661MB | 420MB |
最大構成は、デフォルト設定でバックアップした場合のファイルサイズです。最小構成は、バックアップに必要なファイルだけをバックアップしたサイズです。Duplicatorでは、キャッシュのみをバックアップファイルから除外しています。そして、All-in-One WP Migrationでは、スパムコメント・投稿リビジョン・メディアライブラリ・必須プラグインをバックアップファイルから除外しています。こうやって比較してみると、All-in-One WP MigrationのバックアップファイルはDuplicatorの約2倍になることが分かります。Duplicatorは、All-in-One WP Migrationに比べて、導入時のエラー解決に時間と手間が掛かります。しかし、導入時の幾つかの注意点を抑えておけば、簡単になります。
インストール
Duplicatorのインストールは、まず「プラグイン」の「新規追加」(図1の赤枠)にあるプラグインの検索窓で”Duplicator”と入力します。しばらくの待ち時間の後、”Duplicator”のキーワードを持つプラグインが幾つか表示されるので、”Duplicator-Wordpress Migration Plugin”の「今すぐインストール」ボタンをクリックします(図1.1の青枠)。インストールが完了するとボタンの表示名が「有効化」に変わるので、「有効化」ボタンをクリックします(図1.2の赤枠)。「有効化」ボタンをクリックすると、「インストール済みプラグイン」ページの切り替わります。
 |
 |
| 図1.1 | 図1.2 |
以上で、Duplicatorのインストールは完了です。
サイトのバックアップ
サイトのバックアップは、「プラグイン」ページでDuplicatorの「Manage」をクリックするか(図2.1の赤枠)、左メニューの「Duplicator」で「Packages」をクリックします(図2.2の赤枠)。Duplicatorをインストールした初期はPackageがありません。このため、Packageを作成する必要があります。Packageの作成は、「Packages」ページにある「Create New」ボタンをクリックします(図2.3の青枠)。
 |
 |
 |
| 図2.1 | 図2.2 | 図2.3 |
次に表示されるページには、Name・Strage・Archive・Installerの4つの項目があります(図2.4)。各項目をクリックすると、それぞれの設定項目や入力項目が表示されます。Nameはデータが格納されるzipファイルのファイル名になります。Archiveには、FilesとDatabaseの二つのタブがあり、バックアップするファイルやデータベースを選択できます。その時に応じて、必要なものを選別しましょう。
 |
| 図2.4 |
Duplicatorはバックアップファイルの大きさによっては無料で利用できなくなります。このため、出来るだけ不要なものは削ってバックアップした方が良いです。そして、不要なもので削っても問題なさそうなのは、キャッシュになると思います。キャッシュを削りたい場合は、「Archive」の「Files」タブを選択し、「Enable File Filters」にチェックをします(図2.5の赤枠)。
次に、「Directories」の横にある「root path」・「wp-uploads」・「cache」・「clear」の中から「cache」をクリックします(図2.5の青枠)。そうすると、下にあるテキストボックスにキャッシュが格納されているフォルダのパスが自動で記入されます。記入されたパスを削除したい場合は、テキストボックス内の内容を直接編集するか、「clear」をクリックすると削除できます。
次に、複数のデータベースを扱っていて、特定のデータベースをバックアップしたい場合、「Archive」の「Database」タブを選択し、「Enable Table Filters」にチェックします(図2.6の赤枠②)。バックアップに含まれないテーブルは名前に打消し線が引かれます。Installerには、Host・Host Port・Database・Userなど必要であれば入力します。基本的に、必要性がなければ入力しなくても構いません。「Name」(図2.6の赤枠①)やその他の設定に問題がなければ、「Next」ボタン(図2.6の赤枠③)をクリックすると、System Scanが開始されます。
 |
 |
| 図2.5 | 図2.6 |
System Scanが完了すると、問題のある項目には”Notice”が表示されます(図2.7)。”Notice”の内容に問題がなければ、”Yes. Continue with the build process!”のチェックボックスにチェックします(図2.7の赤枠)。すると、「Build」ボタンが有効化されるので、クリックします(図2.7の青枠)。
 |
| 図2.7 |
今回表示された”Notice”の内容は以下の通りです。ほとんどの内容がファイルサイズに関する警告でした。
| Archive | Filse | Size Checks | Compressing larger sites on some budget hosts may cause timeouts. |
| Database | Overview | Total size and row counts are approximate values. The thresholds that trigger notices are 50MB OR 500,000 records total for the entire database. Larger databases take more time to process. On some budget hosts that have cpu/memory/timeout limits this may cause issues. |
サーバーの設定によっては、アップロードする際のファイル容量が制限されています。これはXAMPPを利用する場合でも同じです。この制限をによって問題が発生した場合、XAMPPの場合、php.iniの以下の設定を変更してください。
- memory_limit = 128
- post_max_size = 8
- upload_max_filesize = 2
post_max_sizeやupload_max_filesizeの大きさは、memory_limitの値以下に設定してください。Scan後に表示されるファイルサイズは圧縮前なのでかなり大きいです。しかし、警告されたキャッシュやテーブルは削除できないものでした。ただし、特定できるプラグインのキャッシュやテーブルで削除できるものであれば、削除しても良いと思います。
Buildが完了すると、必要ファイルのダウンロードページが表示されます(図2.8)。ダウンロードページでは、「One-Click Download」をクリックして一括でダウンロードするか、「Installer」と「Archive」をそれぞれ個別にダウンロードします。
 |
| 図2.8 |
「One-Click Download」をクリックして一括でダウンロードできない場合、ブラウザでポップアップがブロックされている可能性があります。必要に応じて、ポップアップのブロックを解除してください。Chromeの場合は図2.9の赤枠に示すように、アドレスバーの右側にポップアップブロックのマークが表示されます。そのマークをクリックすると図2.10のようなメニューが表示されるので、赤枠の「~のポップアップを常に許可する」を選択し、「完了」ボタンをクリックしてください。
 |
 |
| 図2.9 | 図2.10 |
上記の作業を実行すると、Installer.phpとPackage Setupで指定した名前が付けられたzipファイルがダウンロードされます。以上で、サイトのバックアップは終了です。
XAMPPを利用する上での注意点
今回、XAMPPにインストールされたBitnami WordPressにサイトのバックアップデータを復元するにあたり、幾つかの注意点があります。それは、サーバーのPHPのバージョンと複製するローカル環境にインストールされたXAMPPのPHPのバージョンとで互換性があるということです。PHPのバージョンが新しすぎても古すぎても、利用しているサーバーとXAMPPとのバージョンが合わないとバックアップデータ復元時にエラーが発生する可能性が高いです。そして、利用しているWordpressのプラグインが正常に動作しない可能性もあります。
次に問題になる可能性があるのは、XAMPPに組み込まれているデータベース管理システムがMySQLではなく、MariaDBであるということです。使用しているサーバーのMySQLのバージョンによってはMariaDBとの互換性がなく、バックアップの復元時にエラーが発生する可能性があります。そこで、以下に、PHPのバージョンと、MySQLとMariaDBの入れ替えについて説明します。
PHPのバージョン
当サイトが利用しているサーバーはさくらインターネット 
(以下、さくら)のレンタルサーバー(スタンダードプラン)です。さくらのPHPサーバーのバージョンは、現在、7.1.14が最新です。このため、XAMPPをダウンロードする場合、PHPのバージョンを確認してダウンロードする必要があります。XAMPPのトップページに表示されるXAMPPのPHPのバージョンは常に新しいです。
もし自分が利用しているサーバーのPHPがそれよりも古い場合、図3.1の赤枠に示す緑の矢印をクリックします。次に表示されるページには、トップページよりも古いPHPバージョンのXAMPPがいくつか表示されます(図3.2)。そこでも合うバージョンがない場合は、「その他のダウンロード」をクリックします(図3.2の赤枠)。
 |
 |
| 図3.1 | 図3.2 |
「その他のダウンロード」をクリックすると、各OSごとの項目が掲載されたページが表示されます。今回はWindowsを使用しているので、「XAMPP Windows」をクリックします(図3.3)。次に表示されるページにはこれまでにリリースされたXAMPPが表示されるので、さくらで使用されているPHPと同じバージョン7.1.14を探してダウンロードします(図3.4)。
 |
 |
| 図3.3 | 図3.4 |
もし、Duplicatorの復元時にエラーが発生し、XAMPPのバージョンが異なる場合は、バージョンを一致させるために再インストールしてみてください。これで、PHPのバージョン違いによるエラーの発生は除外されると思います。
MariaDBからMySQLへの置換
さくらのレンタルサーバ 
で使用している当サイトのMySQLのバージョンは5.5.59です。そして、バージョン7.1.14のXAMPPは、MySQLではなく、バージョン10.1.30のMariaDBです。今回利用したXAMPPのバージョンではMySQLとMariaDBとの間で互換性に関するエラーは発生しません。しかし、初めてDuplicatorを扱ったときは、バージョンや互換性も考慮しなかったので、エラーが発生しました。そして、このエラーについて調べると、MySQLとMariaDBの互換性も関係することが分かりました。
2018年1月18日にさくらのレンタルサーバがMySQL5.7を提供開始されているので、バージョン5.7のMySQLとMariaDBとでは互換性によるエラーが生じる可能性があります。このため、レンタルサーバーの環境変化の影響を調べるには、ローカル環境もPHPだけでなくMySQLも今後は一致させる必要があるかもしれません。そこで、MariaDBをMySQLに置換する方法を以下に記載します。
MariaDBからMySQLへの置換に関しては、以下のサイトを参考にしました。
上記二つのサイトはバージョン5.7以降のMySQLについて紹介しています。しかし、今後、MySQLのバージョンを5.7にする可能性があるので、備忘録として紹介させていただきます。
MySQLのダウンロード
まず最初に準備が必要なのは、置き換えるMySQLです。以下のサイトでは、これまでにリリースされた各バージョンのMySQLをダウンロードできます。
デフォルトでは、「Product Version」には最新バージョンが表示されています(図3.5の赤枠)。なので、「Product Version」からサーバーと同じバージョンを選択します。選択するバージョンによっては、「OS Version」の選択が表示されます(図3.6の緑枠)。
Windowsの場合、「Operating System」で「Microsoft Windows」を選択します(図3.6の青枠)。XAMPPのOSのバージョンは32bitなので、「OS Version」で「Windows (x86, 32-bit)」を選択します(図3.6の緑枠)。すると、ダウンロードできる項目が32bitの「MSI Installer」と「ZIP Archive」の二つに絞られるので、「ZIP Archive」をダウンロードします。
 |
 |
| 図3.5 | 図3.6 |
MySQLのインストール
次に、既にXAMPPがインストールされている状態で、XAMPPにあるMySQLのフォルダ名を変更します。このとき、XAMPP Control Panelが起動されていて、かつMySQLも起動されている場合、MySQLを停止してください。XAMPPにインストールされているMariaDBのフォルダの変更前と変更後のパスは以下の通りです。
| 変更前 | c:\xampp\mysql |
| 変更後 | c:\xampp\mariadb |
次に、ダウンロードしたMySQLのZip Archiveを解凍すると、今回のMySQLのバージョンの場合、「mysql-5.5.59-win32」というフォルダに全てのファイルが解凍されます。解凍されたフォルダのフォルダ名から「-5.5.59-win32」を削除し、「mysql」だけにしてXAMPPのフォルダに移動します。この時点で、”c:\xampp”にはmariadbとmysqlの二つのフォルダが存在することになります。このように、フォルダ名を置き換えることで、MariaDBとMySQLの入れ替えを行います。
次に、入れ替えたMySQLにはmy.iniがないので、”c:\xampp\mysql\bin”にmy.iniを新規に作成します。作成したmy.iniには、メモ帳などのテキストエディタで以下の内容を入力して保存します。
[mysqld] # Set basedir to your installation path basedir=c:/xampp/mysql # Set datadir to the location of your data directory datadir=c:/xampp/mysql/data # Default: 128 MB # New: 1024 MB innodb_buffer_pool_size = 1024M
変更点1
久しぶりにMariaDBからMySQLへの置換を実行したところ、これまでの方法では上手くいきませんでした。具体的には、XAMPP Control PanelでMySQLを実行してもすぐにシャットダウンしてしてしまいました。そこで、新たにやり方を調べたところ、以下のサイトでMySQLを実行できるようになりました。
このサイトでは、MariaDBの”C:\xampp\mariadb\bin”にあるmy.iniをコピーし、”C:\xampp\mysql\bin”に設置します。その後、mysqlに設置したmy.iniをメモ帳などのエディタで開き、36行目にあるkey_buffer=16Mの前に#を追記して以下のようにコメントアウトします。
# key_buffer=16M
ここまでの操作が終わったら以下の初期化方法は飛ばして変更点2を参照してください。
MariaDBのdataで初期化する
MariaDBを利用していて、そのdataフォルダの内容をMySQLに引き継ぐ場合はこの操作が必要になります。例えば、MariaDBでBitnami WordPressをインストールしていると、dataフォルダにBitnami WordPressのデータが含まれるので引き継ぎが必要です。MariaDBのdataで初期化する場合、MariaDBのdataフォルダをMySQLのdataフォルダに上書きします。MariaDBのdataフォルダは、MySQLのインストールでリネームしたmariadbフォルダ内にあります。このため、MariaDBのdataフォルダのパスは”c:\xampp\mariadb\data”となります。このdataフォルダをコピーし、MySQLのdataフォルダ”c:\xampp\mysql\data”に上書きします。ただし、このときはファイル名が重複するファイルを上書きすると、XAMPPでMySQLを起動することが出来なくなります。なので、上書きする際に表示されるダイアログボックスでは「ファイルを置き換えずスキップする」をクリックします(図3.7の赤枠)。
 |
| 図3.7 |
上書きが完了したら、XAMPP Control Panelを起動し、MySQLを起動します。
次に、コマンドプロンプトでMySQLのdataフォルダ内にある置換によって破損した可能性のあるデータベースのテーブルの修復を行います。まず、コマンドプロンプトを起動して、以下のコマンドを入力し、binフォルダを指定します。
cd c:\xampp\mysql\bin
そして、以下のmysqlcheckコマンドを入力することで、テーブルの保守を行います。オプションに”–auto-repair”と”–all-databases”を追加することで、データベース内のテーブル全てを対象とし、確認したテーブルが破損していた場合は自動で修復します。
mysqlcheck -u root -p --auto-repair --all-databases
“-u root -p”に関する説明は、以下のサイトを参考にしました。
”-u”はユーザー名を指定するオプションで、インストール直後に登録されているユーザー名が”root”なので、半角スペースを入れて”-u root”とユーザー名を指定します。”-p”はパスワードを指定するオプションで、パスワードを指定する場合は半角スペースを入れずにパスワードを指定します。ここでパスワードを指定せずにコマンドを実行した場合、”Enter Password:”でパスワードの入力を求められます。しかし、パスワードは指定しないので、そのままEnterを押します。”-u root -p”が今後の全てのコマンドで指定されるので、”Enter Password:”でパスワードの入力を求められますが、パスワードを入力しないでください。
データベースの修復を行った後、mysql_upgradeコマンドを入力することで、データベースのテーブルの互換性を確認とシステムテーブルのアップグレードを行います。オプションに”–force”を追加することで、アップグレードを既に実行済みでも強制的にアップグレードを行います。
mysql_upgrade -u root -p --force
テーブルのアップグレードが完了したら、再度、mysqlcheckコマンドを入力します。今度は、オプションに”–check”と”–all-databases”を追加し、全てのデータベースに対してテーブルにエラーがないかを確認します。
mysqlcheck -u root -p --check --all-databases
MySQLのdataで初期化する
MariaDBのdataフォルダの引き継ぎが上手く行かなかったり、不要なデータを削除したい場合などに手っ取り早い解決方法として、MySQLのdataフォルダで初期化するという方法があります。ただし、dataフォルダを初期化すると、Bitnami WordPressのデータはdataフォルダにないので、Bitnami WordPressを再インストールする必要があります。このため、dataフォルダを初期化する場合は、Bitnami WordPressを再インストールする必要があるということを考慮してください。MySQLのdataフォルダ初期化については、自分自身の備忘録として記載しており、バージョン5.7以降では実際には試していない内容が含まれます。このため、信ぴょう性に欠ける可能性があるので、実行する場合は自己責任でお願いします。
dataフォルダを初期化する場合(バージョン5.7以前)
MySQLのdataフォルダを初期化する場合、mysql_install_dbを使用します。mysql install dbはPerlなので、WindowsでPerlを実行する場合はActive Perlをインストールする必要があります。しかし、残念なことに、Windowsでmysql install dbでdataを初期化することが出来ませんでした。ただ、以下のサイトのスライド13では、今回ダウンロードしたZip Archive版のMySQLを推奨しています。
これはZip Archive版では、dataフォルダが作成済みであり、mysql install dbによる初期化が不要だからだそうです。もしdataフォルダを初期化したい場合、既存のdataフォルダを削除し、Zip Archiveから再度dataフォルダをコピペすれば良いだけとなります。今回の場合、MariaDBのdataを引き継ぐ必要がなかったので、最終的にはMySQLのdataをこの方法で初期化しました。
dataフォルダを初期化する場合(バージョン5.7以降)
MySQLのバージョンが5.7以降である場合、dataを初期化する方法が変わりました。
今回はMySQLのバージョンが5.5.59なので関係ありませんが、さくらではバージョン5.7以降のMySQLも提供を始めています。今後、もしMySQLのバージョンを5.7以降にアップデートした場合、dataフォルダを初期化するコマンドを紹介しておきます。まず、コマンドプロンプトで以下のコマンドを入力し、basedirとなるmysqlフォルダを指定します。
cd c:\xampp\mysql
次に、mysqldコマンドを入力しますが、その前にbin\を追加し、以下のコマンドを入力します。
bin\mysqld --initialize-insecure --basedir=c:\xampp\mysql --datadir=c:\xampp\mysql\data
“–initialize-insecure“は、rootパスワードを生成せずにdataフォルダを初期化するオプションです。
“–basedir“ではMySQLがインストールされているフォルダのパスを指定します。
“–datadir“ではMySQLのdataフォルダのパスを指定します。
変更点2
MariaDBと置換したMySQLを初期化する場合、変更点1の手順を終えた後にコマンドプロンプトで以下のコマンドを実行します。最初の行はディレクトリの変更なので、xamppをインストールしたディレクトリ名が異なる場合は任意でコマンドのxamppを変更してください。
cd C:\xampp\mysql bin\mysqld --initialize-insecure start /b bin\mysqld bin\mysql -u root
上記のコマンドを実行すると、mysqlコマンドに変わるので、以下のコマンドを入力します。ここでも2行目にパスを指定しますが、xamppをインストールしたディレクトリ名が異なる場合は任意でコマンドのxamppを変更してください。
CREATE USER pma@localhost; SOURCE C:/xampp/phpMyAdmin/sql/create_tables.sql; GRANT SELECT, INSERT, DELETE, UPDATE, ALTER ON phpmyadmin.* TO pma@localhost; ALTER USER root@localhost IDENTIFIED WITH mysql_native_password BY ''; ALTER USER pma@localhost IDENTIFIED WITH mysql_native_password BY ''; \q
\qでmysqlコマンドを終了し、通常のコマンドに戻るので、以下のコマンドを入力してサーバーを停止します。
bin\mysqladmin -u root shutdown
サイトのインストール
Duplicatorによってサイトをバックアップしたら、次はバックアップしたサイトをローカル環境にインストールします。その準備として、まずBitnami WordPressがインストールされたhtdocsをリネームします。Bitnami WordPressがインストールされたhtdocsは、XAMPPがインストールされた環境では、XAMPPのフォルダ内にあります。例えば、XAMPPをデフォルト設定でインストールした場合、CドライブのルートディレクトにXAMPPがインストールされるので、htdocsがあるパスは”C:\xampp\apps\wordpress”になります(図4.1)。次に、その”wordpress”フォルダ内にある”htdocs”フォルダのフォルダ名を例えば”htdocs_bak”に変更します(図4.2)。次に、”wordpress”フォルダ内に新規に”htdocs”を作成します。このため、”wordpress”フォルダ内には、Bitnami WordPressがインストールされている”htdocs_bak”と、バックアップしたサイトをインストールする”htdocs”の二つが存在することになります(図4.3)。
 |
 |
 |
| 図4.1 | 図4.2 | 図4.3 |
バックアップしたサイトをインストールする空の”htdocs”を開き、その中にサイトのバックアップでダウンロードしたInstaller.phpとzipファイルを移動します。Bitnami WordPressを起動する場合、一番簡単なのはスタートメニューにある「Bitnami 」から「Launch Bitnami WordPress Module」をクリックすることです。通常であれば、Bitnami WordPressが起動されます。しかし、現時点では、htdocsにはWordpressの起動に必要なファイルがないので、エラー403が表示されます。そして、アドレスバーに表示されるアドレスは、”http://127.0.0.1/wordpress/”になります。サイトのインストールを行うには、このアドレスに”Installer.php”を追加するので、以下のURLになります。
http://127.0.0.1/wordpress/Installer.php
上記のURLにブラウザでアクセスすると、Step1のページが表示され、そこにDuplicatorのArchive・Validation・Optionsの三つのメニューが表示されます。ここで問題になるのが恐らく、「Options」に含まれる「General」の「Extraction」の選択だと思います。「Ectraction」には「Manual Archive Extraction」と「PHP ZipArchive」の二つの選択肢があり、デフォルトでは「PHP ZipArchive」が選択されています(図4.5の①)。PHPのバージョンの違いやMariaDBとMySQLとの互換性によっては、「PHP ZipArchive」を選択していると復元が上手くできませんでした。この場合は、「Manual Archive Extraction」を選択することで復元できました。前述したPHPやバージョンを合わせたり、データベースをMariaDBからMySQLに置換してかつバージョンも合わせていれば、「PHP ZipArchive」でも問題なく復元できました。復元環境に合わせて、「Manual Archive Extraction」か「PHP ZipArchive」を選択します。
問題がなければ、「I have read and accept all terms & notices」をクリックします(図4.5の②)。すると、「Next」ボタンが灰色から青色に反転するので、それをクリックします。
 |
 |
| 図4.4 | 図4.5 |
しばらくの間、復元処理が実行された後にStep2のページが表示されます。ステップ2のデータベースのインストールでは、「Setup」の「Database」・「User」・「Password」の入力を行います(図4.6)。これらの項目に入力する値は、先ほどリネームしたBitnami WordPressのインストールディレクトリ”htdocs_bak”にあるwp-config.phpが基になります。基本的に、①「Database」は”bitnami_wordpress”、②「User」は”bn_wordpress”と変わりません。ただし、③「Password」はBitnami WordPressをインストールする度に変更されるので、注意が必要です。もしパスワードが異なる場合、復元時にエラーが生じます。赤色の①~③の項目を入力し、ちゃんと復元できるかどうかを確認したい場合、「Test Database」(緑色の①)をクリックすると、その結果が緑色の②に表示されます。もし「Test Database」でエラーが出なければ、「Next」ボタンをクリックします。次に、インストールを確認するダイアログボックスが表示されるので、「Yes」ボタンをクリックします(図4.7)。
 |
 |
| 図4.6 | 図4.7 |
ステップ3のページでは、サイトの復元が目的なので、テーブルやプラグインを操作する必要がないと思うので、特に設定をすることはありません(図4.8)。もし復元時にエラーが発生し、その原因にテーブルやプラグインが関係しているのであれば、「Scan Tables」や「Activate Plugins」で設定しましょう。基本的には特に設定を変更することなく、「Next」ボタンをクリックします。
ステップ4ページでは、「Site Login」ボタンをクリックします(図4.9)。
 |
 |
| 図4.8 | 図4.9 |
これで、オリジナルサイトのWordpressのログイン画面が表示されます。ユーザー名とパスワードはオリジナルサイトと同じです。もしログイン画面が表示されない場合、wp-config.phpの”DB_HOST”が異なる場合があります。これは、PHPやMySQLのバージョンを一致させる必要があることに気付く前にDuplicatorでサイトのバックアップを復元した際、ポート番号3306が記入されていないということがありました。ひょっとしたら、利用するPHPやMySQLのバージョンによっては起こるエラーが異なるかもしれません。復元したWordpressにログインするとDuplicatorの設定画面が表示されます(図4.10)。
恐らく、多くの人はJetpackがインストールされていると思うので、図4.10のようなメッセージが表示されます。今回の場合、サイトの引っ越しではなく複製なので、Jetpackをセーフモードで実行する必要があります。このため、まず「セーフモードを確認」ボタンをクリックします(図4.10の赤枠)。
次に、Duplicatorのインストールファイルは復元後は必要がないので削除します。削除方法は図4.11の赤枠に示すように、「Remove Installation Files Now!」をクリックします。すると、図4.12に示すように不要ファイルが削除されます。あとは、図4.12の赤枠に示す×ボタンをクリックして終了です。
 |
 |
 |
| 図4.10 | 図4.11 | 図4.12 |
復元時のエラー
Duplicatorで復元する際、幾つかの問題が生じた場合、そのエラーと解決方法について以下にまとめていこうと思います。
Server Code: 200
後日、新たに複数の記事を追加したバックアップを復元しようとしたところ、以下のようなエラーが出て復元できませんでした(図5.1)。どうやら、この問題にはmemory_limitが関係しているようで、memory_limitの値を128から256に変更したところ、無事に復元できました。
 |
| 図5.1 |
しかし、memory_limitを増やしてもエラーが出る場合があり、サーバーコード200について原因を調べてみると、以下のサイトを見つけました。
Duplicatorは、復元する際、htdocsの”wp-config.php”だけを削除して復元することができます。全てのファイルを削除するのが面倒な場合、この方法を行っていました。ところが、最近、原因は分かりませんが、installer.phpとArvhive以外があると、サーバーコード200が出て、エラーになるようになりました。もし、memory_limitを増やしてもエラーが出る場合、htdocsの中身を上記のファイル二つだけにして復元してみましょう。
Sever Code: 0
別のPCで復元を試みたところ、以下のようなエラーが発生しました(図5.2)。
 |
| 図5.2 |
ただ、このエラーに関しては、原因が不明で、DuplicatorのForumでも何故か問題が解決しているようです。
未解決の場合もあるので、こうすれば解決できるというものがありません。
前述したように、Packageを作成する際の「Scan」で、「Archive」の「Files」にある「Size Checks」と「Database」の「Overview」に「Notice」が表示されていました(図2.7)。そして、どちらのメッセージにも共通することは、”some budget hosts”ではファイルやデータベースが大きいとタイムアウトなどの問題が起こる可能性があるということでした。そこで、まず「Size Checks」で削除できそうなファイルを確認し、削除することにしました。図5.3のように削除するファイルのチェックボックスにチェックを付け、「Add Filters & Scan」をクリックします。これで、次回からはチェックしたファイルが「Setup」の「Archive」にある「Files」に登録されます。
 |
| 図5.3 |
次に、「Database」にある「TABLE DETAILS」を確認すると、図5.4に示すようにSlimStatのデータベースが110.16MBとかなり大きいことが分かりました。そこで、「Setup」に戻り、「Archive」にある「Database」でSlimStatに関係のあるデータベースを除外することにしました(図5.5)。
|
 |
| 図5.4 | 図5.5 |
このように不要?なデータベースを削除した結果、無事に復元できるようになりました。もし復元時にServer Code:0が出る場合はプラグインのデータベースが原因である可能性があります。このため、データベースのサイズを確認し、除外しても問題ない場合はPackageから除外しましょう。
文字化け
Duplicatorで復元した場合、データベースの文字列が文字化けするようになりました。
文字化けする原因は様々で、Wordpressが表示するエラーメッセージを頼りに色々と調べて対応しましたが改善しませんでした。
文字化けする原因には、以下が挙げられます。
- 文字コードがUTF-8以外になっている。
- WP Multibyte Patchがインストールされていない。
- 古いMySQLを使用している。
- 復元元と復元先の照合順序が異なる。
- W3 Total CacheなどのWebパフォーマンス最適化プラグインを使用している。
上記以外にDupliactorの設定次第でも文字化けが起こるので、紹介しておきます。
いつから実装されたのか分かりませんが、SQL Modeが「Mysqldump」に設定されていると日本語が文字化けするようです。私自身、この設定を変更した記憶はありませんが、デフォルトでは「PHPコード」に設定されているので、間違えて設定した可能性があります。
設定方法は、まず左のメニューにあるDuplicatorの「設定」→「パッケージ」タブを選択します。次に、データベースのSQL Modeにあるラジオボタンで「PHPコード」を選択します。「モード」にはシングルスレッドとマルチスレッドがありますが、マルチスレッドはProバージョンでしか使えません。クエリー上限サイズは最小が20ですが、デフォルトの100で試すと良いです。
私はこの設定で、Duplicatorの文字化けが解消しました。もし文字化けの原因がつかめない場合、一度、設定を見直すと良さそうです。私は先の文字化けの原因とその解消法を試した後に、この設定変更に気付いたので、問題を解消するのにかなり時間が掛ってしまいました。
最後に
今回、今まで先延ばしにしてきたレンタルサーバー上にあるWordpressのバックアップをPCのローカル環境に復元する方法を試しました。最初は、プラグインを使わずに手動で復元する方法を試しましたが、想像していた以上に難しく、復元できませんでした。そこで、Wordpressのデータベースを復元するプラグインを調べてみたところ、最初にDuplicatorの存在を知りました。
Duplicatorを紹介するサイトが数多くあるので、導入には梃子摺らないと考えていました。しかし、Duplicatorも実際に使用してみると、エラーが頻発し、そのエラーについて解決しているサイトも原因があまり分からずに力技？で何とか導入しているようでした。ただ、私の場合、この力技を試してもDuplicatorで復元することが出来ませんでした。そこで、他のプラグインを探したところ、比較サイトでAll-in-One WP Migrationの存在を知りました。
DuplicatorとAll-in-One WP Migrationと比較サイトを見てみると、All-in-One WP Migrationを勧めるサイトが多いです。実際に試してみると、比較サイトが勧めるだけあって、Duplicatorに比べて復元が簡単でした。ただし、簡単とは言え、無料では容量制限があり、画像などのメディアファイルは後で自分でサーバーにアップロードしなければなりませんでした。また、バックアップファイルがDuplicatorに比べて大きく、将来的にサーバーの容量を圧迫するのでは？という懸念がありました。いずれにせよ、All-in-One WP Migrationで簡単にサイトの復元ができるということが分かりました。そして、再度、Duplicatorでの復元が上手くできない原因を自分なりに試して調べたところ、PHPやMySQLのバージョンの不一致が原因であることが判明しました。PHPやMySQLのバージョンをレンタルサーバーとローカル環境とで一致させると、特に躓く事もなく、復元が出来ました。そして、Duplicatorのバックアップファイルは、All-in-One WP Migrationに比べて、メディアファイルを除外しなくても小さいです。エラーの原因さえ分かれば、Duplicatorの方がAll-in-One WP Migrationよりもメリットがあるように思えます。
当施設では、革細工や織物などの手工芸を用いて、精神病や発達障害など脳に何らかの機能障害を持つ人のカウンセリングをしています。これらの手工芸の動きを様々なセンサーによって数値化し、動きの変化を見てみるとある程度パターン化されることが最近分かってきました。そして、このパターンの変化を追っていくと、そのパターンが崩れる日が出てきます。仮に、このパターンが崩れた日をエラーと考えた場合、このエラーが起こる前日に何があったかをカウンセリングを受ける人に考えてもらいます。そして、この作業を繰り返すことでエラーの原因を特定し、その原因にどう向き合うかを一緒に試行錯誤します。こうすることで、時間は掛かりますが、社会復帰しても問題に対処できる能力を確実に養うことが出来ます。
Duplicatorによるサイトの復元でも色々とエラーが生じて時間が掛かりましたが、今のところ問題なくサイトを復元出来るようになりました。このエラーを調べるために、XAMPPやMySQLの再インストールを何度したことか…。もしDuplicatorによるサイトの復元で行き詰っている人がいれば、この記事が何らかの参考になれば幸いです。
コメント