WP-CLIでデータベースを取り出し、rsyncでファイルをコピーすると、リモートのWordPressをローカル検証環境へ複製できます。
ここではリモート→独立したローカル環境の片方向コピーを扱います。
稼働中の本番へデータベースを戻す双方向同期の手順ではありません。
コピー先と認証を先に確認する
元サイトを扱う権限があり、個人情報をローカルへ保存してよいことを確認します。
コピー先には、本番と接続先が異なる専用データベースを用意してください。
コピーしたサイトのメール送信、決済、Webhook、外部同期などを無効にしてから動作確認します。
インポートはコピー先の既存データを書き換えます。
MacからサーバーへSSH接続するために、Mac側の「リモートログイン」を有効にする必要はありません。
これはMacへの接続を受け付ける設定です。
サーバー側のSSHを設定し、ローカルのSSHクライアントから接続します。
# ローカルのターミナルで確認
ssh -V
rsync --version
wp --infoLocalを使う場合、WP-CLIは対象サイトの「Open site shell」から利用できます。
サーバー側もwp –infoで確認してください。
導入方法はWP-CLI公式のインストール手順を参照します。
古いPHPのパスを固定したエイリアスはコピーしないでください。
SSH接続先を登録する
以下のホスト名、ユーザー、ポート、鍵のパスは説明用です。
契約先の実際の値に変更します。
既存の ~/.ssh/config をバックアップし、他の接続先を消さずに次のHostブロックを追加してください。
初回接続時はホスト鍵のフィンガープリントを信頼できる経路で照合します。
Host waza-source
HostName server.example.com
User exampleuser
Port 22
IdentityFile ~/.ssh/waza-source.pem
IdentitiesOnly yesリモートで非公開の場所へDBを出力する
SSHで接続したリモート側で実行します。
SOURCE_WPはWordPressの実際の絶対パスに変更してください。
$HOME/private-wp-exportがWeb公開ディレクトリの外であることを先に確認します。
SQLには認証情報や個人情報が含まれるため、公開URLで取得できる場所へ置きません。
SOURCE_WP="/home/exampleuser/public_html/example.com"
umask 077
mkdir -p "$HOME/private-wp-export"
wp --path="$SOURCE_WP" option get siteurl
wp --path="$SOURCE_WP" config get DB_NAME
wp --path="$SOURCE_WP" db tables --all-tables
wp --path="$SOURCE_WP" db export "$HOME/private-wp-export/source.sql"--pathは読み込むWordPress設定の場所を選びます。
標準のDBエクスポートが「そのサイトの接頭辞のテーブルだけ」に限定されるわけではありません。
同じDBに別サイトや別用途のテーブルがあれば、そのまま実行せず対象範囲を設計し直します。
上の例は単独サイト専用DBを前提とし、マルチサイトは対象外です。
既存のsource.sqlを上書きしたくない場合は新しい名前にします。
ローカルへ転送し、コピー先をバックアップする
ここからはローカル側です。
SQL保存先もローカルWebルートの外にします。
次の例はmacOSのシェル用です。
umask 077
mkdir -p "$HOME/private-wp-import"
scp waza-source:private-wp-export/source.sql "$HOME/private-wp-import/source.sql"
LOCAL_WP="$HOME/Local Sites/waza/app/public"
wp --path="$LOCAL_WP" option get siteurl
wp --path="$LOCAL_WP" config get DB_HOST
wp --path="$LOCAL_WP" config get DB_NAME
wp --path="$LOCAL_WP" db export "$HOME/private-wp-import/local-before.sql"コピー先のURL・DBホスト・DB名がローカル専用であることを確認してから、次へ進みます。
バックアップの出力失敗時はインポートしません。
Localのapp/sql/local.sqlが常に最新とは限らないため、作業時点でエクスポートします。
次の1行目のwp db importは、SQLの内容をコピー先DBへ実際に反映します。
2行目の--dry-runが保存を止めるのはURLの検索・置換だけで、直前のインポートを試行扱いにしたり、取り消したりするものではありません。
2行をまとめて試す前に、コピー先の接続情報とバックアップを確認し、インポートが成功してから置換予定の確認へ進みます。
wp --path="$LOCAL_WP" db import "$HOME/private-wp-import/source.sql"
wp --path="$LOCAL_WP" search-replace 'https://example.com' 'http://waza.local' --skip-columns=guid --dry-run置換するURLは元サイト・コピー先の実際の値へ変更します。
シリアライズされたデータを壊す単純なSQL置換は避け、まずdry-runの対象と件数を確認してください。
期待どおりなら同じコマンドの末尾の --dry-run だけを外して実行します。
プラグイン独自テーブルや設定ファイルのURLは別途確認します。
ファイルの差分を確認してからコピーする
コピー先のwp-contentを別途バックアップし、次のdry-runで転送予定を確認します。
末尾のスラッシュは「ディレクトリ内の内容」を意味します。
wp-config.phpはコピーせず、コピー先専用のDB接続設定を維持します。
このrsync例の対象はwp-contentだけで、WordPress本体やPHP・データベースサーバーの設定はコピーしません。
rsync -avzn --itemize-changes --exclude='cache/' \
waza-source:/home/exampleuser/public_html/example.com/wp-content/ \
"$LOCAL_WP/wp-content/"対象が正しければ -avzn を -avz に変えてコピーします。
この例は --delete を使わないのでコピー先だけのファイルは残りますが、同名ファイルは上書きされます。
完全なミラーではありません。
サーバー固有のmu-pluginsやキャッシュ設定が含まれる場合は、ローカルで読み込む前に確認してください。
動作確認・復元・本番反映を区別する
ローカルでログイン、記事URL、画像、フォームの送信停止、外部連携の停止、検索エンジンへの公開防止を確認します。
失敗時はローカルのDBとファイルを作業前のバックアップへ戻します。
確認後、転送用SQLの保存期間を決めて管理します。
ローカルDBを本番へ丸ごと戻すと、その間に増えた投稿・会員・注文などを失う場合があります。
旧記事のローカル→リモート一括上書き例は撤回しました。
本番反映は変更するコード・データを特定し、更新停止や差分移行を含む別の手順として設計してください。
本記事のコマンドは現行の実サーバー間転送では未検証です。
参照：wp db export、wp db import、wp search-replace。
環境の作成はWAZAのWordPress記事一覧から確認できます。
よくある質問：WordPressをリモートからローカルへコピーするとき
この記事の方法で、何をコピーできますか？
記事では、WP-CLIでデータベースを取り出し、rsyncでファイルをコピーすると、リモートのWordPressをローカル検証環境へ複製できます。リモートから独立したローカル環境への片方向コピーを扱っていて、稼働中の本番へデータベースを戻す双方向同期の手順ではありません。
コピーする前に、何を確認しますか？
記事では、元サイトを扱う権限があり、個人情報をローカルへ保存してよいことを確認します。コピー先には、本番と接続先が異なる専用データベースを用意します。コピーしたサイトのメール送信、決済、Webhook、外部同期などを無効にしてから動作確認します。インポートはコピー先の既存データを書き換えます。
MacのSSH設定（リモートログイン）は、有効にする必要がありますか？
必要ありません。記事では、MacからサーバーへSSH接続するために、Mac側の「リモートログイン」を有効にする必要はなく、これはMacへの接続を受け付ける設定だと説明しています。サーバー側のSSHを設定し、ローカルのSSHクライアントから接続します。
SSHの設定は、どう扱いますか？
記事では、記事内のホスト名、ユーザー、ポート、鍵のパスは説明用で、契約先の実際の値に変更します。既存の ~/.ssh/config をバックアップし、他の接続先を消さずにHostブロックを追加します。初回接続時はホスト鍵のフィンガープリントを信頼できる経路で照合します。
ローカルにコピーしたあと、URLはどう置換しますか？
記事では、置換するURLは元サイト・コピー先の実際の値へ変更します。シリアライズされたデータを壊す単純なSQL置換は避け、まずdry-runの対象と件数を確認します。期待どおりなら、同じコマンドの末尾のdry-runだけを外して実行します。プラグイン独自テーブルや設定ファイルのURLは別途確認します。
ファイルは、どうコピーしますか？
記事では、コピー先のwp-contentを別途バックアップし、rsyncのdry-runで転送予定を確認します。wp-config.phpはコピーせず、コピー先専用のDB接続設定を維持します。この例では完全なミラーではなく、コピー先だけのファイルは残りますが、同名ファイルは上書きされます。サーバー固有のmu-pluginsやキャッシュ設定が含まれる場合は、ローカルで読み込む前に確認します。
コピーしたあと、ローカルで何を確認しますか？
記事では、ローカルでログイン、記事URL、画像、フォームの送信停止、外部連携の停止、検索エンジンへの公開防止を確認します。失敗時はローカルのDBとファイルを作業前のバックアップへ戻します。
ローカルのデータを、そのまま本番に戻してよいですか？
戻さないでください。記事では、ローカルDBを本番へ丸ごと戻すと、その間に増えた投稿・会員・注文などを失う場合があるとしています。旧記事のローカル→リモート一括上書き例は撤回されています。本番反映は、変更するコード・データを特定し、更新停止や差分移行を含む別の手順として設計します。なお、記事のコマンドは現行の実サーバー間転送では未検証です。
