WordPressのバックアップは、保存できたことと、そのデータから必要な状態へ戻せることを分けて確認します。まずデータベースとファイルの対象・取得日時をそろえ、本番と分離した環境で復元し、表示だけでなく業務に必要な動作まで点検してください。
この記事は、すでにバックアップを取っている企業のWeb担当者に向けた復元テストの設計です。特定プラグインの設定手順や、障害が必ず直る方法を示すものではありません。保守の契約範囲や担当者の決め方は、親記事のホームページ保守の作業範囲と確認事項をご覧ください。
最初に「どの状態へ、何を戻すか」を決める
「最新版がある」だけでは判断ができません。更新失敗の直前、原稿修正の前、画像差し替えの前など、戻したい時点を書きます。選んだバックアップより後の投稿や申込みが、復元によって失われないかも確認します。
一般的なWordPressサイトでは、投稿・設定などを保存するデータベースと、テーマ・プラグイン・アップロード画像などのファイルを組み合わせてページを表示します。WordPress公式資料も、典型的なサイト全体の復元には両方が必要だと説明しています。フォルダーをダウンロードしただけでデータベースまで保存できたとは判断しません。WordPress公式のバックアップ対象で区別を確認できます。
| 戻す対象 | 確認する保存内容 | 見落としやすいもの |
|---|---|---|
| 記事・固定ページ・設定 | 対象サイトのデータベース、取得日時 | 外部サービス側に保存された情報は別確認 |
| 画像・配布資料 | アップロード領域のファイル | 記事の参照だけ戻っても実体がないと表示できない |
| デザイン・機能 | テーマ、プラグイン、独自改修、必要な設定 | 同じ名前でも版や設定が違う場合がある |
| サーバー・外部連携 | 利用環境と復旧に必要な設定の記録 | DNS、メール、外部決済等がサイトのバックアップに含まれるとは限らない |
この表は公式資料を基に作成した一般的な確認表です。SEVEN PEBBLESの顧客サイトを復元した実績や、現在のサーバー構成を示すものではありません。
復元テストは本番と分けて4工程で進める
1. 対象とバックアップの組を確認する
対象URL、ファイルの保存先、データベースの識別情報、取得日時、利用した方法を記録します。別サイトのデータや異なる時点のファイルを取り違えないよう、ファイルとデータベースを一組として扱います。機密情報を含む設定ファイルや認証情報は、誰でも見られる進捗表へ貼り付けず、社内で定めた安全な管理先を参照します。
2. 別の環境で復元する
担当者が用意したテスト環境へ戻し、本番のデータベースや公開ファイルを上書きしないことを確かめます。WordPress公式には開発用コピーを運用する考え方が紹介されています。テスト先のURL、データベース、接続先を明示し、外部のメール通知、決済、予約処理などが本番利用者へ実行されない状態を担当者が確認します。
テスト環境にも個人情報や非公開原稿が入る可能性があります。アクセスできる人を制限し、一般公開や検索登録の対象にしない設計を確認してください。検索エンジン向けのnoindexだけを、閲覧権限の代わりにはしません。
3. 表示と業務動作を確認する
トップページだけでなく、サービス、問い合わせ、最近の記事、画像やPDFを使うページなど、役割の異なるページを開きます。メニュー・リンク・検索を試し、テスト先のフォームでは入力エラー、完了表示、テスト用の通知先への到達まで確認します。通知先を安全に切り分けられない場合は実送信を見送り、未確認として残します。
動作の点検項目は問い合わせフォームの5段階チェックも参考にできます。外部サービスの情報を戻していない場合、サイトの復元完了と外部サービスの復旧完了を同じ結果にしません。
4. 差分と結果を記録する
戻した時点と現在の違いを洗い出します。復元後のサイトが開いても、直近の原稿、送信記録、画像、設定変更が失われるなら、その差分をどう保全するかの判断が必要です。テスト結果を踏まえ、本番へ適用する担当者、承認者、作業時間帯、再確認する機能を決めます。
「戻せる」を判定する復元テスト表
次の表は、バックアップの保存と業務復旧の間にある確認をまとめた本記事独自のひな形です。「合格」「不合格」「未確認」を使い、未確認を合格として扱わないようにします。
| 検査項目 | 合格を判断する材料 | 不足時の対応 |
|---|---|---|
| 取得時点と対象 | 戻したい時点のファイル・DBの組を特定できる | 取得ログや保存対象を管理者と照合 |
| 復元先の分離 | 本番のURL・DB・外部通知先と区別されている | 環境を再確認してから作業 |
| 本文・画像 | 選んだ時点の原稿と画像を代表ページで読める | ファイルの欠落や取得時点を調べる |
| 主要な機能 | メニュー、検索、必要なフォーム操作を完了できる | 再現手順と設定・連携先を記録 |
| 復元後に失われる差分 | 取得後の変更が一覧化され、扱いを承認済み | 新しい投稿・送信記録等の保全方法を相談 |
| 本番へ戻す判断 | 担当、承認、確認項目、連絡先が決まっている | 未定項目を埋めるまで本番作業を開始しない |
記録には「対象URL／バックアップ取得日時／テスト日時／復元先／実行者／検査結果／未確認理由」を添えます。ファイル容量や処理時間は実際に取得した値だけを書きます。テストを実施していない状態で、復旧時間や復旧可能性を数字で約束しません。
取得後の変更と、戻す範囲を見落とさない
WordPress公式のデータベース復元の説明では、現在のデータベースがバックアップ時点の状態へ置き換わることに注意が示されています。障害発見後に新規記事や申込みが増えたサイトでは、復元による巻き戻しが業務へ影響します。
たとえば、更新前のバックアップを検証するときは、「更新後に追加した原稿」「差し替えた画像」「フォームに保存された送信データ」を別々に確認します。これは架空の点検例で、すべてのフォームがWordPress内へ送信データを保存するという意味ではありません。実際の保存先を担当者に確認してください。
同一ドメインに複数サイトがある場合、ホストの復元機能がどの領域を対象にするかも重要です。「このWordPressだけ戻すつもり」が別のサイトまで含む操作にならないよう、利用中のサーバーの公式手順で復元範囲を確認します。
バックアップ運用へ戻すときに決めること
テストで見つかった不足を、保存設定や点検手順へ戻します。取得頻度は更新・受付頻度と許容できる巻き戻し量で考え、どのサイトも同じ回数にはしません。保管場所、保存期間、異常の通知先、担当者が不在のときの連絡先も記録します。
テーマやフォーム、サーバー環境を変更したら、以前のテスト結果が現在の構成でも通用するか見直します。日常の更新との役割分担はWebサイト更新の承認フロー、定期点検の全体像は公開後の運用・改善ガイドへつなげられます。
よくある質問
リビジョンがあれば、サイト全体のバックアップは不要ですか？
不要にはなりません。WordPressのリビジョンは投稿や固定ページの編集履歴を扱う機能です。テーマ、プラグイン、画像ファイルなどを含むサイト全体のバックアップとは対象が異なります。
サーバーの「復元完了」表示で点検を終えてよいですか？
処理完了の確認に加え、対象時点の本文・画像と必要な動作を見ます。表示だけの確認、フォーム通知までの確認、外部連携の確認を分けて記録してください。
テスト環境で成功すれば、本番復旧も保証できますか？
保証はできません。本番の構成、復元時点までの差分、障害原因がテスト条件と違う場合があります。合格条件とテスト範囲を残し、本番適用時にも主要動作を確認します。
参照した一次資料
- WordPress公式：Backups（DBとファイルの保存対象）
- WordPress公式：Backing Up Your Database（DBの復元）
- WordPress公式：Running a Development Copy（本番と開発用コピー）
- WordPress公式：Revisions（編集履歴の対象）
資料確認日：2026年10月14日。図と判定表は一次資料を踏まえた編集上の提案で、実際の復元試験結果ではありません。
