DuplicatorでWordPressを本番と開発環境間で相互に移行する方法

「Duplicator」は、 ローカルPCの開発環境で構築したサイトを本番環境(公開サーバー)に移行したり、反対に公開中のサイトをローカルPCや別サーバー、別ドメインに移行させたりする作業が簡単にできる WordPressのプラグイン です。移行作業時に最大の障害になる内部リンクの書き換えも自動でやってくれ、無料版でも充分に実用的なので使い方を覚えておいて損はないです。

この記事では、WordPressサイトのバックアップをDuplicatorで作成する手順、公開サーバーでバックアップしたWordPressサイトをローカルPCの開発環境に復元する手順、ローカルPCの開発環境で構築したWordPressサイトを公開サーバーに移行させる手順をとおして、Duplicatorプラグインの使い方を解説していきます。

Duplicator のインストール

まず、DuplicatorプラグインをWordPress公式サイトからダウンロードしてご自身のサイト(移行元のサーバー)にアップロードしてインストールするか、管理画面のプラグインの新規追加画面から検索してインストール&有効化しておきましょう。

WordPressサイトのバックアップをDuplicatorで作成する手順

移行元となるサイトでは、Duplicatorを使って サイトのバックアップファイルと移行先のサーバーで展開するためのインストール用のプログラムを作成します。

バックアップファイルとインストール用プログラムのセットを Package(パッケージ)と呼びます。Duplicatorでは複数のパッケージを作成することができ、作成したパッケージはDuplicatorの操作画面で一覧表示されます。

ここでは、サーバーで稼働中のWordPressサイトをバックアップする場合を例に解説していますが、ローカルPCの開発環境にインストールしたWordPressサイトをバックアップする場合でも手順は同じです。文中で「サーバー」と表記している箇所を適宜「PC」と読み替えてください。

なお、ローカルPCでのバックアップファイル(.zip)の作成・解凍処理は、サーバーでの処理に比べて時間がかかります。文中の処理時間に関する表記はサーバーで処理した場合のものです。予めご了承ください。

管理画面左側のメニューからDuplicatorの操作画面を開き、右上のCreate Newボタンをクリックします$

管理画面左側のメニューからDuplicatorの操作画面を開き、右上のCreate Newボタンをクリック

バックアップパッケージの名前を入力し、必要に応じてバックアップから除外するフォルダやファイルを指定したら Next をクリックします$

バックアップパッケージの名前を入力します。

バックアップパッケージの名前は、バックアップファイルの名前の一部としても使用されます。なお 名前欄の下にあるStorage 欄は有料版用の設定オプションです。無料版では保存先が自サーバー内のフォルダに固定されています。

バックアップ除外項目の指定欄

バックアップファイルから除外したいフォルダやファイルがある場合は、Archive(アーカイブ)セクションの Enable file filters にチェックを入れ、フォルダパス・拡張子・ファイルパスなどを指定できます。
キャッシュフォルダやその他のバックアッププラグインで作成されたフォルダなどを指定すると、Duplicatorで作成されるバックアップファイルの容量をある程度抑えることができます。よくわからなければ「ノーチェック&指定なし」でOKです。

フォルダパスの書き方がわからない場合は、入力補助用のボタンをクリックすると自身のサーバーに合わせてプリセットされたパスが自動入力されるので、 自動入力された内容を適宜書き換えると便利です。

Archiveセクションには、上記の他に以下のオプションがありますが、とりあえずここでは使用しません。

Archive Only the Database

WordPress本体やテーマ、プラグイン、画像などのアップロードファイルをバックアップせず、データベースのみバックアップします。これらデータベース以外のバックアップファイルを別途保存してある場合は、このオプションで生成されたバックアップパッケージと組み合わせてサイトを移行したり復元したりすることが可能です。主にバックアップパッケージの生成や展開時にサーバーのタイムアウトが発生する際の対処法としてTwo-Part-Installを実施する際に使います。

Database タブ

Databaseタブに切り替えると、バックアップから除外するデータベース内のテーブルを指定することができます。セキュリティ系のプラグインのブロックログやリダイレクト系プラグインの転送ログなど、移行先で不要となるテーブルを除外指定するとバックアップファイルの容量を少なくすることができます。ただし上級者向けの機能なので初心者は触らない方が無難です。

Installerセクションは有料版で利用できる機能で、無料版では利用できません。移行先でバックアップパッケージを展開する際に入力するサーバー情報をあらかじめ設定したり、バックアップパッケージにパスワードロックをかけたりすることができます。

バックアップファイルを生成するためのスキャンが終わるのを待ちます$

バックアップファイル作成のためのスキャン画面

スキャンはサーバーのスペックやバックアップするサイトの容量にもよりますが、せいぜい1分もかからずに終了します。

スキャン結果画面が出たら、画面下のチェックボックスをONにして Build ボタンをクリックします$

バックアップ前のスキャン完了画面

スキャン結果は 通常 Size Checks 欄の Notice 以外はすべて Good になります。警告が出る場合は その項目をクリックして展開し、指示に従って修正します。

比較的発生しやすいのがName Checks 欄で、画像などのファイル名が日本語になっていたりすると警告がでます。なお、昔のDuplicatorでは、バックアップ容量が500MBを超えるとSize Checks 欄に警告がでて、有料版への移行を促されるようになっていましたが、現在は プラグイン側での容量制限は撤廃されているようです。

バックアップパッケージの生成(Build・ビルド)が終わるまで待ちます$

バックアップパッケージ生成画面

ビルド処理はサーバーのスペックやバックアップするサイトの容量にもよりますが、500MB程度のサイトなら5分程度で終了します。

  • 59.7%あたりになると進捗状況のバーが進まなくなりますが処理は進んでいます。気長に待ちましょう。
  • サーバーのタイムアウトでエラーになる場合は、トラブルシューティングを参照してください。

バックアップパッケージ(2種類のファイル)をダウンロードします$

バックアップパッケージ生成後のダウンロード画面

バックアップパッケージの生成が終わったら 画面中央の InstallerArchive と書かれたボタンをそれぞれクリックして合計2つのファイルをダウンロードします。ボタンの下にある One Click Download を押すと2つ同時にダウンロードすることもできます。
画面右上の Packages ボタンをクリックすると、次の画像のように Duplicator プラグインの最初の画面(パッケージ一覧)に戻ります。

バックアップパッケージ一覧画面

パッケージ一覧画面では、作成済みのパッケージの再ダウンロードや削除などができます。

無料版ではパッケージの保存先が自サーバー内のみなので、バックアップファイルでサーバー容量を圧迫しないためにも、ダウンロードが済んだパッケージは削除しておきましょう。また、無料版ではパッケージにパスワードがかけられないので、セキュリティの観点からも公開サーバー内に長期間パッケージを放置しておくことは避けた方が良いでしょう。

公開サーバーからローカルPCへの移行手順

公開サーバーからローカルPCへの移行は以下の3つのステップになります。なお、今回の解説ではステップ2で使用する開発環境の構築に 無料の Local by Flywheel を使用します。

移行先PCに開発環境を準備する(簡単&無料)

移行先の開発環境にバックアップパッケージを展開する(約15~20分)

移行先PCに開発環境を準備する

今回の解説では、PCに 無料でWordPressの開発環境を簡単に構築できる Local by Flywheel を使用しました。事前に Local by Flywheel を使ってPC内に移行先となるWordPressサイト(ローカルサイト)を新規に作成したうえで、次の画像のようにローカルサイト内の public フォルダ内のファイルをすべて削除しておきましょう。

Local by Flywheel環境選択画面
環境選択画面

Local by Flywheel のバージョンは 5.x 系の最新版を使用します。Ver.5.x 系は従来の3.x系よりも、動作が高速で使いやすくなりました。なお、そのまま構築すると MySQLのバージョンが 8になってしまうので、本番環境がMySQL 5.x の場合は 構築時の環境選択画面で変更してください。

5.x系でうまく移行できない場合は 3.x系を使用することも可能です。Local by Flywheel の各バージョンは 公式コミュニティの Releases トピックから辿ってダウンロードすることができます。

移行先となるローカルサイトを起動しておきます$

開発環境の起動方法

移行先となるサイトを選択し、右上の START SITE をクリックして開発環境を起動します。STOP SITE と表示されている場合は既に起動しているので何もしなくてOKです。

開発環境でhttpsが使えるようにしておきます$

Duplicatorで開発環境をhttps対応にするためのボタン

SSLタブを開き、TRUST ボタンをクリックして開発環境を https対応にします。ボタンが TRUSTED に変化すればOKです。

https対応にしなくても使えますが、https対応にしておくと、開発環境でもログイン時の警告画面が回避できる他、WordPressの管理画面で functions.php や style.css ファイルを編集できるようになります。なお、この操作は開発環境を起動する際、毎回おこなう必要があります。

移行先のデータベース情報をメモしておきます$

Local by FlywheelのDatabeseタブ画面

Local by FlywheelのDatabaseタブで、移行先のデータベース情報をメモしておきます。 この情報は移行先のデータベースをバックアップファイルの内容で上書きする際に必要となります。通常は上の画像と同じになっているはずです。

移行先のWordPress格納フォルダを開き、中のファイルをすべて削除します$

移行先のWordPress格納フォルダ

Local by Flywheelで作成した移行先に格納されているWordPressフォルダをPCのエクスプローラーで開き、中のファイルやフォルダをすべて削除します。なお、ブラウザで移行先サイトを表示していると一部のファイルが使用中となり削除できないので、ブラウザで移行先サイトを表示させている場合は閉じておいてください。

これらのファイルは移行元のバックアップファイルを展開した際にすべて上書きされるのであらかじめ削除しても問題ありません。
逆に、削除しないでも作業は可能ですが、移行先と移行元でプラグインやテーマファイルの構成が異なる場合に、重複しない範囲で移行先のプラグインやテーマファイルが残ったままになります。また、wp-config.php などが残ったままだと、バックアップファイル展開時にDuplicatorで警告がでます。

空にしたWordPress格納フォルダ内にDuplicatorのバックアップパッケージを入れます$

空にしたWordPress格納フォルダ内にDuplicatorのバックアップパッケージを入れたところ

以上で移行先の開発環境に移行元のバックアップを展開する準備が整いました。

移行先の開発環境にバックアップパッケージを展開する

準備が整ったら、Duplicatorのバックアップパッケージを移行先の開発環境に展開します。

ブラウザで移行先のサイトを開きます$

開発環境のサイトをブラウザで開くボタン

Local by Flywheelの画面で移行先となるサイトの VIEW SITE ボタンをクリックしてサイトのトップページをブラウザで開きます。アドレスがわかっている場合は、直接ブラウザで開いても構いません。

開いたトップページのアドレスの末尾に installer.php を書き足し、Enterキーを押して移動します$

トップページのアドレスにinstaller.php を書き足したところ

バックアップパッケージを展開する前なので、トップページを開いても403エラーが出ますが問題ありません。アドレスの末尾に installer.php を書き足してEnterキーを押すと、バックアップパッケージを展開するDuplicatorの画面に移動します。

利用規約の同意にチェックを入れて Next をクリックします$

バックアップパッケージ展開画面1

ブラウザで installer.php を実行すると Duplicatorのバックアップパッケージ展開画面が表示されます。

  • この画面ではバックアップパッケージの展開に支障となるエラーが表示されます。バックアップパッケージを展開するフォルダに既存のwp-config.phpファイルがあるとエラーが表示されるので、その場合はwp-config.phpファイルを削除(別の場所へ退避)させましょう。なお、先ほどの手順で既存のファイルやフォルダを削除していればエラーになることはありません。
  • Options セクションではバックアップファイルから展開されたファイルやフォルダのアクセス権限を変更したり、wp-config.phpファイルの取り扱いを変更したりすることができます。上級者向けのオプションなので通常は使いません。

バックアップパッケージのアーカイブファイル(.zip)が解凍されるのでしばらく待ちます$

バックアップパッケージのアーカイブファイル解凍中の画面

サーバーで実行する処理に比べてローカルの開発環境での処理はパフォーマンスが落ちます。お使いのPCのスペックや展開するバックアップファイルの容量によっては、解凍にかなり時間がかかる場合があります。エラー画面にならない限り気長に待ちましょう。

  • 私の環境では500MBほどのサイトの解凍に7分半かかりました。
  • サーバーのタイムアウトでエラーになるときはトラブルシューティングを参照してください。

移行先のデータベースに接続するための情報を入力して接続テストをおこないます$

移行先データベース接続画面

バックアップファイルが無事に展開されると移行先のデータベースに接続するための情報を入力する画面が表示されます。先ほどLocal by Flywheel でメモしておいたデータベースの情報を入力します。通常は上記画像と同じはずです。入力が終わったら画面下の Test Database をクリックします。

  • ここで入力するのは移行先のデータベースの情報です。移行元のデータベースの情報ではありません。
  • UserやPassword欄に入力するのはデータベースに接続するためのユーザー名とパスワードです。WordPressの管理画面にログインするためのユーザー名とパスワードではありません。

Optionsセクションでは、移行先のデータベースを上書きする際の文字コード周りの取り扱いを変更できます。上級者向けのオプションなので通常は使用しません(初期設定値のままで問題ありません)。

接続テストに問題がないことを確認して Next をクリックします$

接続テスト結果画面

Validationセクションに緑のラベルが表示されれば接続テストはOKです。画面下のNextボタンをクリックします。 移行先のデータベースに接続する情報に誤りがあると接続エラーが表示されて先に進めません。上記ステップ5に戻って正しい値を入力してください。

データベース書き換え処理の最終確認でOKをクリックします$

データベース書き換えの最終確認画面

データベース書き換えの最終確認画面が出たらOKをクリックします。 書き換え後は元に戻せないことと、事前に移行先のバックアップを取っておくことを勧める旨が表示されています。もちろん今回の移行先はまっさらなWordPressサイトなのでバックアップは取りません。

データベース書き換え処理が終わるまで少し待ちます$

データベース書き換え処理中の画面

非力なPCでも、この処理はすぐに終わります(10秒以内)。

必要に応じて書き換え後のデータベースが移行先のドメインで動作するための処理方法を変更します$

更新設定画面その1

基本的には、Setupセクションで移行先サイト名、サイトのURL、WordPressファイルの格納パスだけを設定すればOKです。通常は変更する必要はありません。そのまま Next ボタンをクリックします。これによって、先ほど書き換えられたデータベースや構成ファイルが移行先のドメインで正しく機能するように更新されます。例えば内部リンクや画像、メニューの参照URL、リダイレクト設定などが自動で置き換わります。Duplicatorの素晴らしい点は、この置き換え処理が無料版でも利用できるところです。

  • Replaceセクションは 有料版の機能で、無料版では利用できません。無料版ではカバーできない範囲の置き換え処理ができるようです。
  • Optionsセクションでは、移行先のサイトでのユーザーアカウントやパスワードの差し替え、インストール済みプラグインの無効化、ドメインやファイルパスの置き換え対象をテーブル単位で除外など、データベースや構成ファイルの置き換え・更新処理を細かく制御することができます。上級者向けの設定となるので通常はそのままにしておきます。

データベースと構成ファイルの更新処理が終わるまで少し待ちます$

データベースと構成ファイルの更新処理画面

非力なPCでも、この処理はすぐに終わります(10秒以内)。

更新処理の結果画面が表示されたら画面内のボタンから移行先のサイトの管理画面にログインします$

更新処理完了画面

無事に更新処理が完了したら、「Auto delete installer files after login (recommended) 」にチェックが入っているのを確認して、左の Admin Login ボタンをクリックして移行先サイトの管理画面にログインします。ログイン出来たら上記画像のタブ(Duplicator Step 4of4 )は閉じて構いません。

Auto delete installer files after login にチェックを入れておくと、移行に使用したバックアップパッケージおよび移行用の作業ファイルが自動で削除されます。これらのファイルは移行後は不要なもので、サーバー内に保持しておいても、 第三者による盗用など セキュリティ上のリスクになるだけなので、特段の事情がない限り自動での削除をおすすめします。

移行先サイトのログイン画面

移行先サイトのログイン画面では、移行元サイトのWordPressで使用していたユーザー名とパスワードでログインします。なお、ステップ9のOptionsでユーザー名とパスワードを差し替えている場合は、差し替え後のユーザー名とパスワードでログインします。

ログイン後のDuplicatorの操作画面で 移行関連のファイルが削除されたことを確認して完了です$

移行先サイトのログイン後に表示される画面

上記画面で自動削除に失敗した旨が表示された場合は、画面中ほどにある Remove Installation Files ボタンをクリックして削除を再度実行できます。なおWindowsのエクスプローラーでファイルを直接削除しても構いません。

以下に移行元と移行先での表示を比べてみました。ローカルの開発環境にはアドセンス広告は配信されませんが、それ以外は完全に再現できています。

移行元(公開サーバー)でのサイトの表示
移行元サイトの表示
URL: outlook.aptrust.net
開発環境に移行したサイトの表示
開発環境に移行したサイトの表示
URL: dev.local

ローカルPCの開発環境で構築したWordPressサイトを公開サーバーに移行させる手順

基本的な作業の流れは前述の公開サーバーから開発環境への移行する方法と同じですが、開発環境から公開サーバーへ移行するパターンならではの注意事項があります。

Duplicatorでバックアップパッケージを作る前に、移行元のサイト(ここでは開発環境)をメンテナンスモード=一時的な非公開状態にしてからバックアップパッケージを作成することをお勧めします。理由は以下の2点です。

  • 普通にバックアップパッケージを本番環境に展開すると即座に公開状態になるため、移行処理後の動作確認>公開というプロセスを入れた方が無難
  • Duplicatorでは展開後の.htaccessファイルの内容がリセットされるので、.htaccess にリダイレクト処理やベーシック認証などを記述しているサイトの場合、移行先の環境に合わせて .htaccessファイルを編集する必要がある。

手順の概要

ローカルPCの開発環境から公開サーバーへの移行手順は以下の4つのステップになります。

移行先が稼働中のWordPressサイトの場合、移行先のWordPressサイトのバックアップを作る

例えば現在公開中のサイトをリニューアルしてローカルPCで開発したサイトで置き換える場合などは、万が一に備えて復元できるようにバックアップを取っておきましょう。このバックアップはDuplicatorでなくても構いません。ご自身が確実に復元できると思う方法でどうぞ。もちろんDuplicatorでバックアップパッケージを作ってもOKです。

公開サーバーへ新規のサイトとして移行させるのであれば、失うものは何もないわけで、移行先のバックアップを取る必要はありません。

移行元WordPressでバックアップパッケージを作る(約10分・前述)

前述のとおり、移行元のWordPressをメンテナンスモードにしてからDuplicatorでバックアップパッケージを作成しましょう。私は以下のプラグインを利用しています。

移行先サーバーでの下準備

移行先サーバーでの下準備については2つのパターンに分けて解説します。

  • 移行先に既存のサイトがない場合
  • 移行先に既存のサイトがある場合

移行先サーバーにバックアップパッケージを展開する

サイトのバックアップ方法については既に解説済みですので、このセクションでは3番目の「移行先サーバーでの下準備」から解説します。※サーバーはエックスサーバーを使用しています。 その他のレンタルサーバーをご利用の方は適宜読み替えてください。

移行先サーバーでの下準備(既存のサイトがない場合)

移行先のサーバーに既存のサイトがない場合は、新規にデータベース(MySQL)を作成します。なお、ドメイン(またはサブドメイン)の登録は事前に済ませておいてください。

サーバーパネルにログインし、MySQL設定を開きます$

エックスサーバー サーバーパネル画面

MySQL追加タブから新規にMySQLデータベースを作成します$

MySQL追加画面

MySQL追加タブに切り替え、必要事項を入力して確認画面に進みます。

MySQL追加確認画面

確認画面で「追加する」をクリックして追加完了です。

MySQL一覧タブに切り替えて作成したデータベースにアクセス権所有ユーザーを追加します$

MySQL一覧タブ

追加できるユーザーが1つもない場合(またはユーザーを使い分けたい場合)

MySQLユーザーを新規作成したうえでアクセス権所有ユーザに追加します。MySQLユーザーの作成(=追加)方法はお使いのレンタルサーバーのマニュアルを参考にしてください。

なおMySQLユーザーを新規作成する際は、必ず「MySQLユーザID」と「パスワード」をメモしておいてください

MySQLユーザーがある場合

既にWordPressをインストール済みの場合など、既存のMySQLユーザーがある場合はそちらを利用しても構いません。

サーバーパネルでの作業は以上です。

FTPソフト等で移行先のサーバーにDuplicatorで作成したバックアップパッケージをアップロードします$

FTPソフトでバックアップパッケージをアップロードしたところ

上の画像は、解説用に作成したサブドメイン(dev.aptrust.net)にバックアップパッケージ をアップロードした際のものです。

※Duplicator で作成した installer.phpとxxx.archive.zip の2ファイル

バックアップパッケージのアップロード先は、移行先がサブドメインやサブディレクトリの場合とそうでない場合で異なります。以下の例を参考にしてご自身のサイトに合わせた場所にアップロードしましょう。

移行先がルートドメインの場合

サイトアドレスの例アップロード先
https://aptrust.netpublic_html 直下

移行先がサブドメインの場合(上記画像の例)

サイトアドレスの例アップロード先
https://dev.aptrust.netpublic_html/dev 直下

移行先がサブディレクトリの場合

サイトアドレスの例アップロード先
https://aptrust.net/wppublic_html/wp 直下

以上で移行先のサーバーに移行元のWordPressを展開する準備が整いました。

次の作業:移行先のサーバーにバックアップパッケージを展開する へジャンプ

移行先サーバーでの下準備(既存のサイトに上書きする場合)

上書きしたいサイトのWordPress関連ファイルが保存されているフォルダをFTPソフト等で開き、バックアップパッケージをアップロードします$

FTPアップロード画面

つづいて同じフォルダから .htaccessファイルとwp-config.phpファイルの2つをダウンロードして保存しておきます$

FTPアップロード画面2

wp-config.phpファイルには、バックアップパッケージ展開時に既存のサイトのデータベースに接続するための情報が含まれているので、参照できるようにダウンロードしておきます。.htaccessファイルのダウンロードは必須ではありませんが、リダイレクト処理やBasic認証などのカスタマイズをおこなっている場合は、バックアップパッケージ展開後に再編集する際に参照できるようにダウンロードしておくと便利です。

以上で移行先のサーバーに移行元のWordPressを展開する準備が整いました。

移行先のサーバーでバックアップパッケージを展開する

移行先サイトのトップページを開き、アドレスの末尾にinstaller.phpと書き足してEnterキーを押します$

移行先サイト(展開前)のトップページ

この段階では移行先サーバーにファイルが展開されていないので、サイトのトップページにアクセスしても403エラーが表示されますが、問題ありません。

利用規約の同意にチェックを入れて Next をクリックします$

Duplicator展開画面1

ブラウザで installer.php を実行すると Duplicatorのバックアップパッケージ展開画面が表示されます。

  • この画面ではバックアップパッケージの展開に支障となるエラーや警告が表示されます。既存のサイトに上書きする場合、バックアップパッケージを展開するフォルダに既存のwp-config.phpファイルを検知すると Overwrite Install の項目で警告Warn が表示されますが、間違って上書きしないためのものなので無視して構いません。
  • Options セクションではバックアップファイルから展開されたファイルやフォルダのアクセス権限を変更したり、wp-config.phpファイルの取り扱いを変更したりすることができます。上級者向けのオプションなので通常は使いません。

移行先のデータベースに接続するための情報を入力して接続テストをおこないます$

Duplicator展開画面2

バックアップファイルが無事に展開されると移行先のデータベースに接続するための情報を入力する画面が表示されます。入力方法は移行パターンに合わせて以下を参考にしてください。

移行先サーバーに複数のMySQLデータベースを運用している場合は、入力するMySQLデータベースを間違えないように注意しましょう。

既存のサイトに上書きする形で移行する場合$

既存のサイトに上書きする形で移行する場合は あらかじめ保存しておいた移行先サイトのwp-config.phpファイルをWindowsのメモ帳などで開き、該当する項目を上記画面にコピペします(ダブルクォーテーション は含みません)。

wp_config.php内の該当部分
wp-config.phpファイルの例
移行にあたって新規にMySQLデータベースを作成した場合$

移行にあたって新規にMySQLデータベースを作成した場合は以下を参考にして必要事項を入力しましょう。

Host欄

ご利用のレンタルサーバーのMySQLホスト名を入力します。エックスサーバーの場合は MySQL設定画面のMySQL一覧タブで確認できます。

エックスサーバーのMySQLホスト名情報欄
エックスサーバーの場合

Database欄

前述の②で追加した MySQLデータベース名を入力します。

User/Password欄

前述の③で追加したMySQLユーザー名とパスワードを入力します。

接続テストに問題がないことを確認して Next をクリックします$

接続テスト結果画面

Validationセクションに緑のラベルが表示されれば接続テストはOKです。画面下のNextボタンをクリックします。 移行先のデータベースに接続する情報に誤りがあると接続エラーが表示されて先に進めません。上記ステップ3に戻って正しい値を入力してください。

データベース書き換え処理の最終確認でOKをクリックします$

データベース書き換えの最終確認画面

データベース書き換えの最終確認画面が出たらOKをクリックします。 書き換え後は元に戻せないことと、事前に移行先のバックアップを取っておくことを勧める旨が表示されています。

データベース書き換え処理が終わるまで少し待ちます$

データベース書き換え処理中の画面

必要に応じて書き換え後のデータベースが移行先のドメインで動作するための処理方法を変更します$

更新設定画面その1

基本的には、Setupセクションで移行先サイト名、サイトのURL、WordPressファイルの格納パスだけを設定すればOKです。通常は変更する必要はありません。そのまま Next ボタンをクリックします。これによって、先ほど書き換えられたデータベースや構成ファイルが移行先のドメインで正しく機能するように更新されます。例えば内部リンクや画像、メニューの参照URL、リダイレクト設定などが自動で置き換わります。

  • Replaceセクションは 有料版の機能で、無料版では利用できません。無料版ではカバーできない範囲の置き換え処理ができるようです。
  • Optionsセクションでは、移行先のサイトでのユーザーアカウントやパスワードの差し替え、インストール済みプラグインの無効化、ドメインやファイルパスの置き換え対象をテーブル単位で除外など、データベースや構成ファイルの置き換え・更新処理を細かく制御することができます。上級者向けの設定となるので通常はそのままにしておきます。

データベースと構成ファイルの更新処理が終わるまで少し待ちます$

データベースと構成ファイルの更新処理画面

更新処理の結果画面が表示されたら画面内のボタンから移行先のサイトの管理画面にログインします$

更新処理完了画面

無事に更新処理が完了したら、「Auto delete installer files after login (recommended) 」にチェックが入っているのを確認して、左の Admin Login ボタンをクリックして移行先サイトの管理画面にログインします。ログイン出来たら上記画像のタブ(Duplicator Step 4of4 )は閉じて構いません。

Auto delete installer files after login にチェックを入れておくと、移行に使用したバックアップパッケージおよび移行用の作業ファイルが自動で削除されます。これらのファイルは移行後は不要なもので、サーバー内に保持しておいても、 第三者による盗用など セキュリティ上のリスクになるだけなので、特段の事情がない限り自動での削除をおすすめします。

移行先サイトのログイン画面

移行先サイトのログイン画面では、移行元サイトのWordPressで使用していたユーザー名とパスワードでログインします。なお、ステップ7のOptionsでユーザー名とパスワードを差し替えている場合は、差し替え後のユーザー名とパスワードでログインします。

ログイン後のDuplicatorの操作画面で 移行関連のファイルが削除されたことを確認して完了です$

移行先サイトのログイン後に表示される画面

上記画面で自動削除に失敗した旨が表示された場合は、画面中ほどにある Remove Installation Files ボタンをクリックして削除を再度実行できます。なおWindowsのエクスプローラーでファイルを直接削除しても構いません。

サイトの動作確認、.htaccessの編集を経て、メンテナンスモードを解除したら移行作業はすべて完了です。$

Duplicatorによるサイト移行作業が完了したら、サイトの動作確認をおこないましょう。すでに述べた通り.htaccessファイルは初期状態にリセットされているので、リダイレクト処理やBasic認証などを.htaccessファイルに記述する必要がある場合は.htaccessファイルの再編集も忘れずに。

リセット前の.htaccessファイルは、バックアップパッケージ(.zipファイルの方)の中に htaccess.orig という名前で保存されています。

最後にメンテナンスモードを解除して移行作業はすべて完了です。お疲れ様でした!

トラブルシューティング

Duplicatorを使って移行するサイトは千差万別なので、エラーが出てうまくいかな場合の対処法をすべて紹介することはできません。Duplicatorの公式サイトでは、ユーザーガイドやFAQ、トラブルシューティングに関する文書が充実しているので、大抵のエラーには対処できるはずです。

レンタルサーバーとローカルPCの開発環境で作業している場合に多くの方が遭遇するのは 、サーバーのタイムアウトで バックアップパッケージの生成や展開処理が止まるケースです。

Duplicatorでサイトを移行する通常の作業では、バックアップパッケージに WordPress関連ファイル(WordPress本体、テーマ、プラグイン、画像などのアップロードファイルなど)が含まれますが、これらの合計容量が増大するほど パッケージの生成や展開(主にzipファイルの圧縮と解凍)の処理に負荷と時間がかかりすぎるのが原因です。

Host Build Interrupt screen
タイムアウトで処理が中断した画面の例

上記の画面のようにタイムアウトでパッケージ生成処理が中断した旨の表示が出ても「なんちゃってタイムアウト」の場合もあります。バックアップパッケージの保存先フォルダをFTPソフト(ローカル環境の場合はエクスプローラー)で表示させて、10秒おきぐらいの間隔で更新してみてファイルサイズが変化しているようであれば処理が進んでいます。この場合は、ファイルサイズの変化がなくなるまで待ってから、Duplicatorのパッケージ一覧画面に戻りましょう。

なお、中断した画面で各対処法の見出しをクリックすると詳しいヘルプを参照することができます。主要な4つの対処法の概要は以下のとおりです。

Try DupArchive

通常はzipファイルを使って生成するバックアップパッケージを DupArchiveという独自の方法で生成することにより、大容量のサイトでもエラーが発生しにくくします。ただし、無料版のDuplicatorでは DupArchiveの容量が500MBに制限されているので、無料版を使う方には現実的な選択肢ではありません。

File Filters

バックアップパッケージ生成する際に Archiveセクションで指定できるオプションで、フォルダやファイル、データベーステーブルをバックアップから除外することで、パッケージの容量を削減する方法です(前述)。バックアップに不要なキャッシュフォルダなどを指定すれば、ある程度の容量を削減できます。

画像などのメディアファイルが原因でサイトの容量が大きくなっている場合は、画像ファイルのフォルダを除外して当該フォルダだけ手動で移行させても良いでしょう。

Two-Part Install

上のFile Filters がWordPress関連ファイルの一部を除外する方法をとるのに対して、Two-Part Install はWordPressのデータベース(MySQL)だけで構成されるバックアップパッケージを生成し、WordPress関連ファイルは別途手動で移行させます。Duplicatorで実行する処理が最小限になるため、無料版のDuplicatorでできる最も確実なタイムアウト対策です。

Configure Server

サーバー側の設定を変更してタイムアウトを回避します。上級者向けの機能です。

Two-Part Install のポイント

ここでは、最終手段ともいえる Two-Part Install の手順のポイントとなる部分を解説していきます。慣れてしまえば簡単ですが、初心者の方はLocal by Flywheel で2つのサイトを作成して、相互に移行させる練習をすると良いでしょう。

バックアップパッケージの作成時には Archive Only the Database にチェックを入れる$

バックアップパッケージの設定画面

パッケージとしては installer.phpと xxx.archive.zip の2ファイルが作られますが、zipファイルの中身は 移行元のwp-config.phpファイル、.htaccessファイル、データベース、展開時に必要となるDuplicatorのプログラムのみで、せいぜい数MB程度のサイズになります。

WordPress関連ファイルは手動で保存する$

Two-Part Install ではWordPress関連ファイルは保存されていないので、移行元サイトのWordPress関連ファイルが格納されているフォルダ ※1の中身を丸ごとダウンロードして保存します。

※ルートドメインで運用しているサイトなら通常は public_htmlフォルダ になります。サブドメインやサブディレクトリで運用している場合は public_htmlフォルダ 直下に該当のフォルダがあるのでそちらの中身を丸ごと保存します。

WordPress関連ファイルをFTPソフトなどでそのままダウンロードすると膨大な時間がかかるので事前にサーバー側でzipファイルに圧縮したものをダウンロードすることをお勧めします。

移行先サーバーの下準備では Duplicatorのバックアップパッケージと 手動で保存したWordPress関連ファイルをアップロードする$

Two-Part Install で作成したDuplicatorのバックアップパッケージにはWordPress関連ファイルは含まれていないので、上記2で保存したWordPress関連ファイルを手動でアップロードしておきます。

手動アップロードした時のフォルダ構成のイメージ
手動アップロードした時のフォルダ構成のイメージ

ダウンロードの時と同様、WordPress関連ファイルをFTPソフトなどでそのままアップロードすると膨大な時間がかかるので事前にzipファイルに圧縮したものをアップロードし、サーバー側で解凍することをお勧めします。

バックアップパッケージを展開する作業は基本と同じ$

Two-Part Install が通常の作業と異なるのは、WordPress関連フォルダの圧縮と解凍を Duplicator 内蔵のプログラムを使用せずに手動でおこなう点と、バックアップパッケージは 「Archive Only the Database」のオプションを使って生成したものを使うという点の2つだけです。

上記ポイントの1~3に従ってWordPress関連フォルダを移行元から移行先へ適切に移動できさえすれば、バックアップパッケージを展開する作業以降は基本と同じになります。

DuplicatorのバックアップパッケージだけでTwo-Part Installをする方法

通常のTwo-Part Installでは、データベースだけを格納したDuplicatorのバックアップパッケージと、別途手動で用意したWordPress関連フォルダのバックアップを組み合わせますが、移行先フォルダにアップロードしたDuplicatorのxxx.archive.zipを手動で解凍したうえでinstaller.phpを実行することも可能です。

この場合、 installer.php実行後の最初の画面で Overwrite Install 欄に 警告Warn が表示されますが、画面下のOptionsで Manual Archive Extraction を選択することで 次のステップに進むことができます。Manual Archive Extraction を選択すると Duplicatorによる xxx.archive.zip の解凍処理がスキップされるので、解凍処理のタイムアウトによるエラーを回避できます。

Duplicator Manual Archive Extraction
Manual Archive Extraction に切り替える

いかがでしたか?当サイトは記事数が少ないくせに5回ぐらい テーマファイルの入れ替えに伴うサイトのリニューアルをしていて、Duplicatorにはいつもお世話になっています。

ちなみに、Duplicatorの他に人気のあるバックアップ系無料プラグインといえば UpdraftPlus ですが、両者の守備範囲は大きく異なります。
サイトの日常的なバックアップをするなら、ボタン一つで定期的な自動バックアップもできる UpdraftPlusを、リニューアルやレンタルサーバーの引っ越しなどを予定している方は、バックアップファイルを使った異なるドメイン間の移行処理も無料で出来る Duplicator を使用しましょう。

以上Duplicatorプラグインの使い方でした。