WordPressの復元テストはどう進める？別環境でページ・画像・ログインを確かめる

会社サイトのバックアップを、本番を上書きせず試したい担当者へ。

同じ保存分のファイルと、投稿・設定を保存するDBの控えを、本番と分けた検証先へ戻します。ページ・画像・ログインを個別に試し、取込の完了と使えることを分けて確認します。

何を戻し、どの動きを確かめるか決める

復元テストは、保存した内容を読み戻し、必要な表示や操作ができるか確かめる作業です。バックアップを持っていることは出発点であり、その保存物でサイトが動くことまで確認した結果ではありません。まず、どのサイトの、どの保存分を試すかを決めます。

WordPressは、画像・テーマ・プラグインなどのファイルと、投稿本文や設定を保存するDB（データベース）を組み合わせて動きます。対象サイトと保存時点が対応する両方の控えを選び、必要な部品が含まれるかを確認してください。近い取得時刻だけで中身の整合性を証明せず、保存中の更新をどう扱ったかも確かめます。

試すページと操作は、会社サイトで止まると困るものから選びます。たとえば、トップページ、画像を含むサービス紹介、管理者のログイン、問い合わせ画面の入力確認です。保存時点の内容がどう見えるはずかを先に決めると、古い保存分を戻しただけの状態と、復元後の不具合を混同しにくくなります。

最新版との違いをすべて障害と扱わないでください。保存後に書き換えた紹介文が検証先にないなら、その保存時点では含まれていなかった可能性があります。期待する保存版の本文・画像と比べ、対象外のページや、今回まだ試さない操作も分けておきます。

この先では、検証先の準備、保存物を戻す操作、表示と機能の確認、試験後の扱いの順に説明します。利用する保存製品や契約先によって操作画面は違うため、ここで示す確認順と、その環境で承認された復元手順を組み合わせます。

ファイルとDBの対応や保存先がまだ整理できていない場合は、先にWordPressのバックアップを一組で取得・保管する方法で保存物を確かめてください。この記事では、そろえた控えを別環境へ戻し、動きを試すところから扱います。

本番から分けた復元先を用意する

本番は、訪問者が使い、問い合わせや編集が増え続ける公開サイトです。検証先は、その本番と分けて試すための場所です。「ステージング」という名前が付いていても、接続先や送信先まで自動的に分離されたとは決めつけず、実際の構成を確認します。

復元操作の前に、検証先のURL、ファイルを置く場所、接続するDBを、本番の情報と照合します。DBは検証用に用意したものを使い、現在の本番DBへ読み込まないようにします。どちらの環境を開いているかは、ブラウザーのURLと、契約先の管理画面にある対象名の両方で確かめてください。

WordPressの接続情報を持つ wp-config.php も確認対象です。これは、どのDBを使うかなどの基本設定を保存するファイルです。本番から複製した設定がそのまま本番DBを指していれば、見た目だけ別のサイトにしても安全な試験先とは言えません。接続情報の確認・変更は、その環境を管理する担当者が検証先に限定して行います。

検証先には、復元した投稿、会員情報、問い合わせの控えなどが含まれる場合があります。利用を許可されたデータと閲覧者を決め、契約先の機能などでアクセスを制限します。URLを知らせないことと、アクセスを制限したことは別です。

メール、問い合わせ受付、決済、外部サービスへの通知なども、動かす前に扱いを決めます。検証用の送信先や連携先へ切り替えるのか、送信自体を止めるのかを確認し、実顧客へ届く状態で試しません。送信条件が決まらない間は、画面の表示や入力確認までを試験範囲とし、送信の動作確認は未確認として残します。

WordPress公式の試験用環境の説明にも、公開先の外で試す考え方があります。ただし古い製品画面や設定例を含むため、そのクリック手順や接続例を現在の契約環境へそのまま写す資料にはしません。

ファイルとDBの同じ組を、検証先へ戻す

保存した原本はそのまま残し、復元作業にはそのコピーを使います。圧縮された保存物なら作業用コピーを展開し、ファイル側とDB側の対象サイト・保存分が対応するかを確かめます。必要な保存物を特定できない段階では、手近な別のDBと組み合わせて試験を始めません。

1. 検証先のファイルを用意する。 保存されたWordPress本体、利用中のテーマ・プラグイン、アップロード画像など、今回の復元に必要な対象を検証先へ戻します。必要な部品や配置方法は保存方式の説明で確かめます。
2. 検証用DBへ保存分を読み込む。 DBの書き出しは、投稿や設定を読み戻すための保存物です。たとえばSQL形式の書き出しを使う場合は、検証用DBを選んだことを確認してから取り込みます。ファイルを置いただけでは、この取込まで終わったことにはなりません。
3. 接続と参照先を確認する。 検証先のWordPressが、そのDBを読み込む設定になっているかを担当者が照合します。別URLで試す場合は、ページ内の参照先やログイン後の移動先が本番へ戻らないかも確かめます。

ファイルとDBを扱う考え方は、WordPress公式のバックアップと復元の案内で確認できます。製品が一括で戻す方式なら、その手順に従って各対象の結果を読みます。別々に操作する方式であっても、使った保存分と戻した対象が分かるようにします。

取込に使う管理機能がphpMyAdminの場合も、最初に選ぶDBが重要です。phpMyAdminはDBをブラウザーから操作するための道具です。公式のDBをバックアップから戻す説明では、取り込み先を選んで保存ファイルを読み込む流れと、現在のDBを保存時点へ戻す影響が説明されています。古い画面のボタン位置ではなく、検証先を選んだことと、対象の取込結果を確認してください。

別URLでの試験に必要な参照先の調整は、使う製品の対応方法を確認します。保存ファイルの文字列をすべて単純置換したり、本番と同じDBへ上書きしたりする手順を一律には使いません。URLや接続先を変える具体的な作業は、WordPress移行の接続先・URL参照の確認手順が参考になります。本稿の復元試験は本番の切替を目的にしません。

ページ・画像・ログインを一つずつ試す

保存物を戻す処理が完了したら、実際に開いて確かめます。結果は、ページ表示、画像、ログイン、入力、外部送信などを分けます。トップページが開いたことだけで、管理画面や問い合わせまで動いたことにはしません。

ページと画像を確かめる

検証先のURLから、最初に決めた代表ページを開きます。保存版にあるはずの見出しや本文が出るか、ページ内のリンクが予定した検証先へ進むかを読みます。画像は、画像を含むページで表示されるかを確かめ、必要なら読み込み先も確認します。本番の画像を外から読んで表示できているだけなら、検証先へ画像を戻せた証拠とは分けます。

ログインと入力を確かめる

許可された担当者が検証先のログイン画面を開き、予定した利用者で入れるか、必要な管理画面が開くかを確かめます。ログイン後に本番へ移動していないかもURLで確認します。IDやパスワードの実値を確認記録へ貼り付ける必要はありません。

問い合わせ画面では、項目が見えること、選択や入力ができること、入力誤りの案内が出ることを順に試します。画面に完了表示が出ること、メールが送られること、会社側で受付を確認できることは、それぞれ別の結果です。送信する試験は、検証用の宛先と外部連携の条件を確かめた範囲だけで行います。

架空の検証サイトAには、同じ保存時点のファイルとDBを戻したという設定と、両方の完了記録、トップ表示の記録があります。しかし、画像・ログイン・外部送信・本番側の変化・原因は未確認です。別の検証サイトBにはファイル配置の記録だけがあり、DBの取込とトップ表示も未確認です。BはAの修正後ではありません。

Aで次に確かめるのは、まだ記録のない画像やログインなどの結果です。Bでは先に、対応するDBの保存物があるか、検証先へ取り込んだ記録があるかを調べます。二つを同じ「復元済み」という一語にまとめると、残っている作業が見えなくなります。

違いと未確認を分け、同じ条件で確かめ直す

期待した表示と違ったときは、どのページ・操作で、何を期待し、実際には何が見えたかを分けて確認します。「画像が見えない」「ログイン後に別URLへ移った」などは、観測した内容です。その時点で原因をDBの破損、プラグイン、契約先の不具合などと決めつけません。

たとえば画像だけが表示されない場合は、対象の画像ファイルを戻したか、読み込み先がどこか、同じ保存版のページと画像かを確認します。ログインが通らない場合は、試した検証先と利用者、画面の案内、移動したURLなどを確かめます。これらは原因を絞るための確認例であり、今回の架空記録で発生した障害や確定原因ではありません。

確認していない項目は「未確認」、期待どおりでなかった項目は実際の表示や案内を残します。記録がないことを失敗に、完了表示だけを成功に置き換えません。第三の架空例は資料の照合から未確認であり、復元に失敗した例でも正常な例でもありません。

修正する場合は、対象と理由を決めたうえで、同じ保存分・検証先・ページ・操作で確かめ直します。変更した箇所だけでなく、その変更が関係する画像やログインなども必要な範囲で確認します。条件を変えた試験なら、その違いを残し、前回と同じ結果だとは扱いません。

試験先での確認が済んでも、本番の状態を測ったことにはなりません。保存後の更新、公開先の構成、接続・送信条件が異なれば結果も変わります。実環境の原因調査や修復に進む場合は、観測できた内容と許可された操作範囲を基に判断します。

検証の終了と、本番に戻す判断を分ける

検証の終わりには、どの保存分を、どの検証先へ戻し、どの表示や操作を確かめたかを整理します。未確認の項目を残したまま「サイト全体の復元成功」とせず、今回の試験範囲で何が分かったかを示します。外部送信や本番側の変化を確かめていないなら、その状態を維持します。

試験後の検証先を残す期間、閲覧できる人、不要になったデータの扱いは、環境を管理する担当者が決めます。保存したバックアップ原本と試験結果は、検証先を片付ける作業と分けて扱います。片付ける対象を確認せず、本番のファイルやDBを削除しません。

本番を実際に戻す場合は、試験と別に判断します。保存時点よりあとに増えた問い合わせ、投稿、注文、設定変更が、その保存分には含まれないことがあります。現在の状態を別に保全し、後日分の扱いと戻す範囲、作業する時点、確認担当を合意してから実作業へ進みます。

注文や図面などを扱う業務システムまで復旧対象が広がる場合は、業務システム全体の復元テスト計画で、戻す対象や許容する古さ、再開時間、停止中の受付を含めて整理できます。WordPressの表示確認と、会社の仕事を再開できる条件は、目的に応じてつなげてください。

全三記録の項目は、図のすぐ下にある補足で読み比べられます。資料が未照合の記録を、失敗・正常・ゼロのいずれにも置き換えません。

まとめ：戻す先と確かめる動きを先に決める

WordPressの復元テストは、対応するファイルとDBを本番と分けた検証先へ戻し、ページ・画像・ログインなどを個別に試す作業です。取込の完了表示と、実際に使える機能の結果を分けると、残る確認が具体的になります。

まず、試す保存一組と検証先を特定し、本番へ書き込まない接続・送信条件を確かめてください。そのうえで代表ページを一つ選び、保存版にあるはずの本文と画像を開いて確認します。画像やログインなどを試していなければ、未確認として次の操作へ残します。

別環境で表示を確認したことから、本番の全機能、保存後の問い合わせや注文の安全性まで保証はできません。本番へ戻す判断と実操作は、現在の状態と後日分を守る条件を確認した別工程として扱います。