「毎日バックアップを取っています」と聞いていても、何をどこまで戻せるか分からなければ、障害時の判断は難しくなります。記事を消した場合、画像を上書きした場合、更新後にサイトが止まった場合では、必要な復元対象が違います。保存の仕組みと、実際に戻す手順を分けて確認しましょう。
保存している対象を確認する
WordPressのバックアップでは、データベースとファイルを区別します。記事や設定などを保存する部分と、テーマ・プラグイン・画像などの部分は役割が異なります。WordPress公式のバックアップ資料を参考に、自社で保存している対象と、保存していない対象を一覧にしてください。
サーバー会社の自動保存があっても、メール、別サービスのデータ、外部フォームの記録まで含まれるとは限りません。複数のサービスを使う場合は、それぞれに保存方法が必要です。サイト全体を戻せると思っていた範囲と、契約上の対象が一致しているかを確かめます。説明資料が見つからない場合は、サポート窓口へ確認します。
保存日時と保持期間を確かめる
障害の直前に戻したいと思っても、その時刻のデータが残っているとは限りません。毎日の保存なのか、手動の作業時だけなのか、何日分を残すのかを確認します。更新が頻繁なサイトでは、一日前へ戻すだけでもその後の投稿や受付データが失われる可能性があります。保存の頻度は業務の変化量に合わせて考えます。
問題が起きた日時が分からない場合は、最新の保存にも問題が含まれていることがあります。複数時点の保存が必要な理由はここにあります。何日分あれば十分かは一律に決められませんが、気づくまでの期間や保管容量を含めて相談しましょう。自動保存の成功通知だけでなく、失敗時に誰へ知らせるかも決めておきます。
保管場所とアクセス権を整理する
本番サーバー内にだけ保存すると、そのサーバーへ入れないときに使えない場合があります。別の保管先へ取り出す方法や、管理会社が復元する方式を確認してください。一方、保存先を増やすほど管理すべき情報も増えます。個人情報や設定値を含むバックアップは、閲覧できる人と保管期間を決め、安全な場所で扱います。
バックアップファイルをWebから取得できる場所へ置かないことも重要です。ファイル名を長くするだけではアクセス制限の代わりになりません。管理用の権限や保管設定は技術担当者へ確認しましょう。担当者の個人端末にだけ残す方法も、異動や故障時に困るため、会社として引き継げる保管先を選びます。
復元する人と判断する人を決める
サーバー会社が自動で保存していても、復元は自社の操作が必要な契約があります。有料の作業依頼や申請が必要な場合、緊急時の連絡先と受付時間を把握しておきましょう。ログインできる人だけでなく、業務データをどの時点まで戻してよいか判断する人も決めます。古い状態へ戻すことは、新しい変更を失う可能性を伴います。
復元時には、障害後に追加された記事や申込情報を別に保全する必要があるかを検討します。全体の復元と、一つのファイルや記事だけを戻す方法では影響が違います。障害の原因や範囲が分からないまま何度も戻すと、調査の手がかりが消えることもあります。作業前の状態を記録し、担当者と方針を共有してください。
テストで確認して初めて分かること
可能であれば、公開中のサイトを上書きせず、別の環境で復元を試します。保存データが読み込めるか、画像がそろっているか、管理画面へ入れるかを確かめます。外部サービスへの送信やメールが発生しないよう、検証環境の扱いも整理してください。顧客情報を含むデータを使うなら、アクセス制限と管理範囲が必要です。
復元の成功は、トップページが表示されたことだけで判断しません。代表的な記事、資料、フォーム、更新操作など、自社に必要な機能を確認します。所要時間も記録しておくと、停止時間の見込みを共有する材料になります。ただし一度の試験が将来の復元を保証するわけではないため、構成が大きく変わったときは見直します。
復元が必要な場面を三つに分ける
一つ目は、記事の一部分を誤って消した場合です。本文の変更履歴で戻せるなら、全体のDBを復元するより影響を小さくできる可能性があります。二つ目は、画像ファイルを上書きした場合です。本文を戻しても元画像が復元されるとは限らず、ファイルの保存が必要になります。三つ目は、システム更新後に全体が動かなくなった場合で、複数の対象を組み合わせて戻す判断が必要です。
このように障害の種類によって手段が違うため、「最新のバックアップへ戻す」を唯一の対処にしないことが大切です。どこに問題があり、どのデータを残す必要があるかを確認します。小さな修正で済むのか、全体の復元が必要なのかを担当者と相談してください。業務上のデータを失う可能性がある場合は、事業側の承認も含めた判断が必要です。
古い状態へ戻す前に、その時点以後の変更を調べます。投稿、設定、会員や申込みなど、サイトの用途によって保全対象が変わります。どれを別に取り出せるか、戻した後に再反映できるかも確認します。障害が起きた状態を保全する必要がある場合は、アクセスできる人と保管先を限定しましょう。調査用のデータを公開場所へ置かないようにします。
不正な変更が疑われる場合は、保存データ自体に問題が含まれていないかも確認が必要です。戻せば必ず安全になるとは限りません。原因の調査、認証や環境の見直しなど、復元以外の対応も担当者と検討します。緊急時に焦って何度も上書きする前に、必要な情報を残して対応の順序を決めることが重要です。
復元試験の結果を使える記録にする
試験の記録には、使った保存日時、対象ファイルとDB、復元先、実行した手順、かかった時間、確認した機能を入れます。成功という言葉だけより、何が利用できたかが分かる方が役立ちます。ログイン、記事、画像、フォーム、外部連携などの結果を分けると、未確認の範囲も見えます。テスト環境では外部送信を止めたため受信は未確認、といった条件も残します。
保守担当が変わる場合は、この記録と保管先を引き継ぎます。前任者の端末や認証だけに依存していないか、必要な権限を会社として利用できるかを確かめてください。二段階認証の回復方法も含め、緊急時に必要な手続きが分かることが大切です。パスワードそのものを一般の手順書へ書くのではなく、安全な管理方法を別に用意します。
試験で復元できなかった場合は、保存範囲の不足、手順の不足、環境の違いなどを整理します。問題があるまま「バックアップ済み」とだけ報告せず、何を直すかと再確認の担当者を決めます。復元の前提を整えることが、保存の仕組みを増やすより先に必要な場合もあります。自動保存の回数だけを指標にしないようにしましょう。
構成変更や外部サービスの追加があったときは、復元資料も見直します。以前の試験で使えた手順が、新しい構成にも当てはまるとは限りません。定期的な確認の頻度は、サイトの更新量と業務への影響に合わせて相談します。保存、確認、復元、引き継ぎの四つがつながっている状態を維持することが、実際に使える備えになります。
日常の変更記録と組み合わせる
障害時に「いつから何が変わったか」が分かると、戻す時点を探しやすくなります。システム更新、機能追加、サーバー設定変更の履歴を残しましょう。文章の変更履歴と、サイト全体のバックアップは用途が違うため、両方の役割を理解しておくと対応を選びやすくなります。軽微な修正のたびにフォルダー全体を複製する運用は、管理の混乱にもつながります。
ホームページ保守・管理サポートを検討する際は、「保存していますか」だけでなく、「何を、いつの状態へ、誰が、どの方法で戻せますか」と聞いてください。答えが分かる資料を一枚にまとめ、緊急時に見つけられる場所へ置くことが、バックアップを実際に使える備えへ変える第一歩です。