バックアップの管理画面に「成功」と表示されている。それでも、障害が起きた日に本当にサイトを戻せるかは、別の確認が必要です。保存したファイルを開けない、データベースが含まれていない、復旧に必要なアカウントへ入れない、といった問題が後から見つかることがあります。
WordPress保守では、バックアップを作ることと、使える状態で保管し、復元できることをセットで考えます。本番を壊して試すのではなく、隔離した環境で行う復元テストの考え方を整理します。
ファイルとデータベースの両方が必要
WordPressの公式ドキュメントでは、典型的なサイトを完全に復元するには、ファイルとデータベースの両方が必要だと説明されています。画像やテーマを保存しただけでは、記事や設定を戻せません。逆にデータベースだけでも、画像や独自のコードはそろいません。
同じ時点の一組として管理することも重要です。大きく時刻の違うデータを組み合わせると、画像を参照する記事はあるのにファイルがないなど、不整合が起きる可能性があります。更新や受注が続くサイトでは、整合性を保つ保存方法を保守担当と検討します。
保存先へ入れるか、取り出せるかを確かめる
バックアップサービスの契約者と、実際に復旧を行う人が違う場合は、必要な権限と連絡経路を確認します。前任者の個人アカウントや、多要素認証の端末がないと取り出せない状態では、いざというときに止まってしまいます。
バックアップが本番サーバーと同じ場所にしかないと、そのサーバー全体の故障や侵害に巻き込まれるおそれがあります。別の場所への保管、世代の管理、削除権限、暗号化と復号手段を確認してください。外へ保存する場合も、誰でもダウンロードできる場所へ置いてはいけません。
復元先を本番と取り違えない準備をする
テストは本番とは分離した環境で行います。データベース名、接続先、ドメインを作業前に照合し、復元先を間違えない手順にします。顧客情報を含むコピーを、誰でも見られる検証サイトとして公開しないでください。アクセス制限と検索除外は別に考えます。
コピーしたサイトがメールや通知、外部API、決済、予約連携を実行しないよう、復元したものを動かす前の遮断を計画します。自動処理も対象です。画面を開いてから気付くのでは遅い場合があるため、必要な通信を止めた隔離環境から始めます。
トップページが出ただけで完了にしない
表示の確認では、トップページ、主要な固定ページ、記事、画像、管理画面を見ます。フォームや予約を確認するときは、本番の宛先や顧客へ通知が飛ばないテスト設定を使います。ログイン、検索、ダウンロードなど、そのサイトで重要な機能を一覧にしておきましょう。
PHPやデータベースのバージョン、必要な拡張機能、サーバーの設定が異なると、同じデータでも動かない場合があります。また、DNS、メール、外部サービスの契約や秘密情報など、WordPressのバックアップだけではそろわないものもあります。復旧に必要な周辺情報の保管場所も確認します。
どこまでの損失と停止を許容できるか
毎日バックアップしていても、復元時点から障害発生までの問い合わせや受注が戻らない可能性があります。「何時間分までのデータ損失を許容するか」と「何時間で再開したいか」を、業務側と相談しておきます。バックアップの頻度だけでなく、復元にかかる時間も評価します。
ECや予約サイトでは、古いデータへ丸ごと戻すことで、決済済みの注文や確定済みの予約と食い違う危険があります。障害直前の記録や外部サービスの履歴と突き合わせる手順が必要です。単純なロールバックをすべてのサイトに当てはめないことが大切です。
侵害されたサイトは、戻すだけで安全とは限らない
不正アクセスが原因なら、バックアップ自体に改ざんが含まれていないかも確認が必要です。元の脆弱性や漏れた認証情報が残っていれば、復元後に再び侵害される可能性があります。通常の更新失敗と、セキュリティ事故の復旧を同じ手順だけで扱わないでください。
調査記録を保全し、原因への対応、必要な認証情報の失効、復元対象の選定を専門家や保守担当と相談します。「昨日のデータだからきれい」とは限りません。
テスト結果を次の担当者へ渡す
- 使ったバックアップの日時と、保存されていた範囲
- 復元先、前提条件、遮断した外部通信
- 復元にかかった時間と、詰まった手順
- 画面・機能の確認結果と、未確認の項目
- 本番復旧時に別途必要な承認や連絡
定期的なテストと、大きな構成変更後の確認を予定に入れます。バックアップの価値は、ファイルが存在することではなく、必要なときに正しく再開できることです。その確かさを積み上げることが、保守の品質につながります。
