ホームページのバックアップ復元テスト｜確認手順と記録項目
Web制作編集：株式会社AO
バックアップファイルが保存されていても、必要なデータが揃っていない、復元手順が分からない、保存先まで障害の影響を受けた、といった理由で戻せないことがあります。本番を直接上書きせず、安全な検証環境で復元し、表示と業務機能まで確認して初めて「使えるバックアップ」と判断できます。
- 復元テスト前に決める範囲と完了条件
- 本番へ影響を与えない確認手順
- 次回の復旧を速くする記録項目
バックアップ対象を一組で確認する
WordPress公式ドキュメントでは、一般的なサイトの復元にはファイルとデータベースの両方が必要と説明されています。テーマやプラグイン、画像だけを保存しても、投稿・設定・ユーザー等が入るデータベースが欠ければ元の状態には戻せません。外部ストレージ、DNS、メール配信、決済など、サイト外の依存先も台帳に分けて記録します。
| 対象 | 確認する内容 | 見落とし例 |
|---|---|---|
| サイトファイル | テーマ、プラグイン、アップロード、設定ファイル | 画像や独自設定だけ欠ける |
| データベース | 投稿、固定ページ、設定、利用者情報 | ファイルだけ保存している |
| 実行環境 | PHP等のバージョン、拡張、権限、接続情報 | 復元先で動作条件が違う |
| 外部連携 | フォーム、メール、解析、決済、API | 画面は見えるが通知されない |
| 保管情報 | 作成日時、世代、暗号化、保管先、担当者 | 障害と同じ場所にしかない |
復元テストの合格条件を決める
「トップページが開いた」だけでは完了にしません。どの時点までのデータを戻すか、何時間以内に主要機能を再開したいか、誰が完了を判断するかを先に決めます。NISTは復旧計画を、停止後にシステム・業務・データを回復するための計画、手順、技術的対策の組合せとして整理しています。自社では、重要ページ、問い合わせ、更新、ログイン、外部連携など、事業への影響が大きい順に合格条件を置きます。
検証環境で復元する手順
- 対象のバックアップ世代と作成日時を記録し、改ざんや破損の兆候がないか確認する。
- 本番と分離した検証環境を用意し、検索エンジンの登録や実メール送信、決済実行を防ぐ。
- 利用中の基盤に合う公式手順に従い、ファイル、データベース、設定、権限を復元する。
- トップだけでなく、主要ページ、画像、管理画面、フォームの入力から通知までを確認する。
- リンク切れ、表示崩れ、エラーログ、想定外の利用者・ファイルを点検する。
- 開始から業務上必要な機能の確認までの時間と、つまずいた箇所を記録する。
- テスト用の認証情報や送信データを削除し、検証環境を適切に閉じる。
結果を記録して次回へつなぐ
実施日、対象世代、復元先、担当者、開始・完了時刻、合否、未確認項目、手順との差分を一枚にまとめます。失敗した場合も、データ不足、権限、容量、バージョン差、外部連携のどこで止まったかを残すと改善につながります。サイト更新や基盤変更の後は、手順書とテスト条件も更新します。
実施チェックリスト
- ファイルとデータベースを同じバックアップ組として識別できる
- 本番と分離した検証環境とテスト用認証情報を用意した
- 検索登録、実メール、決済など本番動作を防いだ
- 主要ページ、管理画面、フォーム、外部連携の完了条件を決めた
- 作業時間、失敗箇所、手順変更を記録した
- 侵害時はクリーンな世代かを別途確認した
よくある質問
自動バックアップがあれば復元テストは不要ですか？
自動化されていても、対象漏れや破損、権限不足、復元先との環境差は確認が必要です。保存成功の通知と、業務機能まで戻せることは分けて考えます。
本番サイトで試してもよいですか？
原則として、分離した検証環境で行います。本番を上書きすると現行データの消失や二重送信につながるため、やむを得ない場合は保守会社と停止、退避、切戻しの手順を決めてください。
どのくらいの頻度で確認しますか？
サイトの更新頻度、許容できるデータ損失、停止時の影響、基盤変更の有無で決めます。全社一律の回数ではなく、重要な変更後や担当交代時にも実施できる運用にします。
参考にした公式情報
- WordPress Developer Resources：Backups
- NIST CSRC：Contingency planning
- Google Search Central：My site's been hacked - now what?
公式情報の確認日：2026年10月21日。本文の表・手順・チェックリストは、公式情報を踏まえたAO編集部の実務向け整理です。個別環境の復元可否や所要時間を保証するものではありません。