【バックアップ編 〜 まとめ】「ワードプレスをワンクリックで爆速お引っ越し!」その3 【 All-in-One WP Migration 】

長かった三部作(笑)も最終回。
これまでの記事で「 All-in-One WP Migration 」が優秀なことは伝わっただろうか(笑)

バックアップ

都度のバックアップ

都度バックアップを取るのは、その名も「バックアップ」というメニューがあるのでそちらから。

「 All-in-One WP Migration 」メニューの「バックアップ」

このメニューから「バックアップ」を選択すると

「バックアップ」選択画面

これまでのバックアップファイルの一覧が表示される。このバックアップファイル群は wp-content/ai1wm-backups に保存されている。

ここで「バックアップを作成」ボタンを押下すると

バックアップファイル作成中の画面

エクスポート時と同様の画面が表示され、エクスポートが完了すると

バックアップファイルのダウンロード画面

「{{ドメイン名}}をダウンロード」のボタンが表示される。
これをクリックすれば

バックアップファイル作成後のファイル管理画面

無事に自分のパソコンの任意の場所にエクスポートされた .wpress ファイルがダウンロードされ、同時にサーバー上の wp-content/ai1wm-backups にもファイルが保存される。

なんかこれだけだと「エクスポート」と何も変わらない(笑)ような気もするのだが、実際は「エクスポート」を選択した場合は以前の記事でも書いたようにオプション設定があり、エクスポート「しない」項目を選ぶことができる。「バックアップ」の場合はその選択がないのでとにかくすべてのファイル群とデータベースのデータがバックアップされる、という違いがある。

ちなみに、バックアップファイル一覧の画面では、ファイルの項目右側に

ダウンロード

バックアップファイルのダウンロード選択画面

復元

バックアップファイルの復元選択画面

削除

バックアップファイルの削除選択画面

のメニューがあり、それぞれのファイルの管理ができる。
この画面から過去のバックアップファイルのダウンロードや削除、また数クリックで以前の状態に復元することも可能、というわけだ。

バックアップが非常に手軽にできるのはもちろん、復元も同様に手軽にできるのはとても良い。
ただし、これだけでは「定期的なバックアップ」を取ることはできない。

「バックアップもできるけれど、本来の使い方はデータのインポート・エクスポートで、バックアップはその補足的な意味」ということだろう。

定期的なバックアップ

定期的にバックアップを取りたい場合、一般的にはバックアップ用のプラグインを使うのがいいだろう。
有名どころのバックアップ用プラグインであれば、定期的にバックアップを取得したり、Google Drive や Dropbox などの外部サービスと連携してバックアップしたファイル群を一定の数だけ保存したりすることができるものは多くある。

とはいえ、「 All-in-One WP Migration 」を使っていると All-in-One WP Migration 専用のファイル形式( .wpress ファイル)でバックアップを取得しておいて、リカバリーしなければならなくなったりしたときに(ほぼ)「ワンクリック」で復元したい、という要望は一定数あるだろう。

そこに関しても抜かりはない(笑)
ちゃんと定期的なバックアップ用のエクステンションが用意してある。

エクスポート先選択画面

以前の記事でデータをエクスポートする際に、エクスポート先に「ファイル」を選択する、と説明した。
が、ご覧のとおりエクスポート先にはそれ以外の方法も色々選択できる。「ファイル」以外の形式でエクスポートする場合には、それぞれ別途エクステンションが必要になるというわけだ。

これらのバックアップ用のエクステンションはそれぞれ $99 。これを高いと考えるかどうかはそれぞれの使い方や運用の体制次第だろう。インポートのときのエクステンション( Unlimited Extension )と同様に一度購入すればずっと使い続けられるので、複数のサイトを管理していたり、前述したように手軽に復元したい、となれば高くはないのではないだろうか。
もちろん、エクステンションを購入する際に外部サービスの利用料だったり、保存容量や使い勝手などを検討する必要はあるだろう。

例えば「 Google Drive 」を選択した場合は、以下のような画面に遷移する。

Google Drive Extension 購入画面

その他のサービスを選択した場合でもほぼ同様の手順になるので、ここでは「 Google Drive 」を例に説明を進めることにする。

画面上の「今すぐ購入 $99」のボタンをクリックして購入手続きが済めばエクステンションがダウンロードできるようになるので、管理画面の「プラグイン>新規追加」から .zip 形式のファイルをアップロードし、有効化すればよい。

有効化すると、管理画面左カラムの「 All-in-One WP Migration 」のサブメニューに「 Google Drive Settings 」が増えているのがわかる。

「 All-in-One WP Migration 」サブメニュー

「 Google Drive Settings 」をクリックすると、まずは自分の Google アカウントとの紐づけをする画面が表示される。

Google アカウント選択画面

紐づける Google のアカウントを選択すると、紐づけを許可するかどうかの確認画面に遷移するので、間違いなければ「許可」ボタンをクリックする。

Google アカウントへのアクセス許可画面

許可すると管理画面内の設定画面になるので、各設定をする。

Google Drive Settings 画面

設定の簡単な解説

Google Drive Settings 画面詳細
① Configure your backup plan

ここでバックアップを取る時間を入力する。「毎時」「毎日」「毎週」「毎月」を選択すると、その項目に応じて例えば「毎週日曜の0時」などの設定が可能。

② Destination folder

Google Drive 内のどのフォルダにバックアップを保存するかを設定する。デフォルトでは新たにドメイン名のフォルダが作られる。「 CHANGE 」ボタンで保存フォルダの変更が可能。

③ Notification settings

バックアップが成功したらメールを送信する、または失敗したらメールを送信する、の設定が可能。メールを送信する先のメールアドレスも変更できる。

④ Retention settings

バックアップを保存しておく上限を設定する。バックアップファイルの世代数での上限(5個を超えたら古いものから削除、とか)か、容量での上限(3GB を超えたら古いものから削除、とか)を制限にして設定可能。

⑤ Transfer settings

転送速度によってタイムアウトするまでの時間を変更できる…のかな?(笑) ここはちょっと不明。

設定を変更して最下部の「 UPDATE 」を押下すれば設定が反映される。
注意点としては、有効化した瞬間に最初のバックアップが取られるわけではないこと。まず最初にバックアップしておきたいなら、都度のバックアップの手順でバックアップしよう。

設定にはない使い方の注意点

これらの外部サービスと連携して定期的にバックアップしたファイル群だが、実は wp-content/ai1wm-backups にも同時にファイルが保存されるところも都度のバックアップと同様。
これについてはちょっと機能として微妙だと思っていて、せっかく外部サービスと連携してそちらにバックアップファイルを一定数あるいは一定のファイル容量まで保存する、としているのだから、 正直サーバーの中のファイルはいらないのだ…。
外部サービスでバックアップが完了したら/バックアップが失敗したらメールを送る、という設定ができるのだから、バックアップが完了したら wp-content/ai1wm-backups に作られたバックアップファイルは削除する、という設定があってもいいのではなかろうか。

実はそういう設定はあるけど僕が見つけられていないだけのかな…?

制作者的立場からみる「 All-in-One WP Migration 」活用ポイント

長編三部作となってしまった「 All-in-One WP Migration 」解説記事もようやく終わりを迎えようとしている(笑)
いやー、実際こんなに長くなるとは自分でも考えていなかった。確かに気に入っているのは間違いないのだが…。

ここまでは「ユーザー」の視点で使い方をひととおり説明してきたのだが、ここで「制作者」という視点から All-in-One WP Migration の使い勝手・使いどころを紹介したい。

僕自身が All-in-One WP Migration を使う最たるシチュエーションは『公開環境を開発環境に移す』場合。このとき All-in-One WP Migration は絶大な威力を発揮する。

実際問題、業務としての WordPress 環境の開発であれば GitWP-CLI を使うのは当たり前になってしまっているので、そこまで All-in-One WP Migration を最大限利用している、という程でもないというのが正直なところ。

ただ、例えば新規のクライアントさんの環境(サーバーに Git が入っていない、CLI とかもない)をクローン(完全コピー)してローカル環境(またはステージング環境、開発環境など)を作りたいようなときに、プラグインを入れてポチポチしているだけでできてしまうのは時間もかからず非常に楽だ。

これまで環境の移設(完全コピーを作るなど)する場合、まずファイル一式を FTP などでダウンロードし、データベースは PHPMyAdmin でダンプして…とかまぁ手間がかかった。
というか、一般的には今でもそうやってるよね(´・ω・`)

「仕事」として web 制作をしている現場では前述したように Git と WP-CLI はもう必須条件になってしまっているが、それがない環境であっても(もちろん事前に「プラグインをひとつ追加します」のお断りは必要だが)簡単にその環境を作れるのは非常にありがたく、とても便利に使っている。

サーバーのことをよくわかっていないクライアントさんにサーバーの環境だとか詳細の情報を聞かなくてもまずは手軽に複製が作れる、という点もとてもスマートだと思う。
もちろん、実際にはいずれ詳細は聞かなくてはならないが、WordPress にログインできさえすれば(そしてプラグインインストールの許可さえ得られれば)即、開発環境が用意できるようになったのは工数削減の観点からもとても喜ばしいことだ。

(あまり見かけない)利用する際の注意事項

とにかく制作者の立場からしても大絶賛の All-in-One WP Migration なのだが、利用にあたってちょっとだけ注意点もあるので一読しておいてほしい。この点に関してはユーザー・制作者に限らず利用する場合は誰でも気をつけておきたいポイントになる。

「ローカル環境を公開環境に移設する」場合はデータの上書きに注意

第2弾の記事の中で、『「データで完全に上書きされるけどいい?」というアラートが出る』という説明文を書いたのだが、データをインポートする際には文字どおり全部の設定を上書きする。
新規にサイトを公開する、あるいはサーバーを移設するのであれば問題ないのだが、運用中のサイトでの開発環境から公開するような場合、公開環境だけで入力されている記事や設定はすべて消えてしまう。いわゆる「先祖がえり」になってしまうのだ。
実際にこういう場面で上書きしてしまった、ということは幸いなことにまだないのだが(笑)、基本的に「ローカル(開発)環境 → 公開環境」の上書きは『新規公開の場合だけに限る』と思っていたほうがいいだろう。

普段の運用に使うのは今回の「引っ越し〜」の趣旨からはちょっと離れてしまうし、そもそも All-in-One WP Migration もそういう使い方は想定していないだろう。

とにかく全部の環境がそのまま移設されるので「 Jetpack 」に代表されるような「サイトで連携している web サービス」の設定も注意が必要

例えば All-in-One WP Migration を使ってステージングサイトを作るような場合、「 Jetpack 」の設定によってステージング環境側が「本サイト」と認識されてしまうことがあったりする。
その場合はステージングサイトの設定に明示的に「このサイトはステージングである」と記載する必要がある。

Jetpack の場合、具体的には wp-config.php ファイルに

define( 'JETPACK_STAGING_MODE', true );

の記述を一行適切な場所に書き加えておけばいい。

他にも、例えば Google Anlytics の設定であったり、 SNS への自動投稿であったり、プラグインでなにかしらの web サービスと連携しているものがあるならば要注意である。

プラグインを無効化するだけであれば、そのプラグインの設定はデータベースに残ったまま保存されているので、All-in-One WP Migration でインポートしたらすぐに web と連携しているプラグインは無効化するのがいいだろう。

もうひとつつけ加えるならば、管理画面の「設定>表示設定」の『検索エンジンでの表示』のチェックが外れたままになっていてステージング環境が Google にインデックスされてしまう、なんてことも起こりうるので、そこも要注意。これに関しては、公開環境でないなら Basic 認証を付与しておくだけでもよさそう。

ソースを Git 管理してる場合も注意

特に業務で利用している場合 Git も使っている場合が往々にしてあると思うが、これもうっかり不用意にプラグインから上書きすると Git 上での差分が大量に出てしまったりするので注意が必要。
もちろん必要ならば git commit し、不要ならば git reset すればいいのだが、差分があまりに大量だった場合どれを commit し、またどれを reset すればいいのか判断に苦しんだり間違えてしまうこともあるだろうし、あとからそのコミットを見て「この大量の差分はなんだったんだ…?」とかなってしまうのでは Git を使っている意味が半減してしまう。
Git を使っているならば、ソースコードはやはりそちらで管理するのがいいだろう。

実際問題、前述したように Git を使っている案件では All-in-One WP Migration が活躍する場はちょっと少ないのも事実だ。

最後に 〜 まとめ

長々と「 All-in-One WP Migration 」の使いかた、あるいは使うシチュエーションなどを解説してきたが、このプラグインをどれだけ気に入っているか、という点については伝わったのではないだろうか(笑)。

もちろん他にもこういったプラグインはたくさんあるし、これだけがあればいいというものでもない。
例えばバックアップについてなどは、「どうしても」ということがなければ「バックアップ用プラグイン」として一般的に使われている有力なプラグインのほうが無料で機能も充実しているので充分だろうし、サーバーへの復元の機能も含んでいるプラグインもある。定期的なバックアップも無料の範囲内でできるものが多い。

とはいえ、いわゆる「サイトのお引っ越し(サーバー移設)」がこんなにも簡単にできるようになった、というのはとても素晴らしいことだし、とても喜ばしいことだ。

最後に少しだけ記載した注意事項も、「プラグインの使い方として注意すること」というよりは「引っ越しや復元、運用の際に気をつけること」なので、 All-in-One WP Migration に限らず注意は必要だろう。

ぜひとも「 All-in-One WP Migration 」を上手に利用して、このアホほど長い記事を読んでくださった方々が安全でラクにサーバーの引っ越し・環境の移設ができることを願うばかりだ。

とはいえやっぱり、結論としては All-in-One WP Migration 、最強です。