01

1. 復旧したい業務から対象を決める

最初に、障害後に何を復旧できれば業務を再開できるのかを決めます。WordPress本体、テーマ、プラグイン、アップロード画像などのファイルと、記事、ユーザー、設定を含むデータベースは別の対象です。問い合わせフォームや予約機能を使う場合は、送信先や外部サービスの設定も確認項目へ加えます。

会社用メールを同じサーバーで運用していても、WordPressのバックアップだけではメールを戻せない場合があります。Web、データベース、メールを分けて一覧にし、それぞれの取得方法、保存期間、復元方法をサービスの公式案内で確認します。

  • WordPressのファイル一式とアップロード画像
  • 記事・ユーザー・各種設定を含むデータベース
  • 問い合わせフォームと外部サービスの接続情報
  • 同じ契約で運用している会社用メール
02

2. 自動バックアップの範囲と期限を読む

レンタルサーバーの自動バックアップは有力な復旧手段ですが、保存対象、保持日数、取得や復元の操作はサービスごとに異なります。契約中のプランで何が保存され、どの画面から取り出せるのかを確認し、案内ページのURLと確認日を運用記録へ残します。

保持期間より前に起きた不具合や、気付くまで時間がかかった改ざんは、自動バックアップだけでは戻せないことがあります。保存日数を知ったうえで、月次など別の周期で社外へ保管するコピーが必要かを判断します。

  • 自動取得の対象と実行間隔
  • 利用できる世代数または保持日数
  • 取得・復元に必要な権限と操作
  • プランやサーバーによる例外条件
03

3. サーバー外にも復旧用コピーを保管する

同じサーバー内だけにバックアップを置くと、契約停止、アカウント侵害、誤削除などで本番と同時に使えなくなる可能性があります。自動バックアップを補う復旧用コピーは、アクセス権を限定した別の保管先へ定期的に移し、本番用の認証情報と同じ場所へ集めないようにします。

保存先を増やすほど安全になるとは限りません。古い個人端末や共有範囲の広いフォルダに複製すると情報漏えいの面が弱くなります。保管担当者、暗号化、保存期限、削除方法を決め、必要な世代だけを管理します。

  • 本番サーバーと障害原因を共有しない保管先
  • バックアップを閲覧できる担当者
  • 暗号化と復号に必要な情報の保管場所
  • 保存する世代数と期限後の削除方法
04

4. 復元する時点と影響範囲を先に決める

復元では、選んだ日時より後に追加された記事、注文、問い合わせなどが失われる可能性があります。障害の種類と発生時刻を確認し、どの日付のファイルとデータベースを使うか、復元前に現在の状態を別途保存するかを決めます。

ファイルだけを戻すのか、データベースも戻すのかで影響は変わります。作業前に更新を止める範囲、利用者への案内、作業担当、切り戻し条件を一枚へまとめ、表示が戻っただけで完了にしない受け入れ条件を設定します。

  • 障害または誤操作が始まった時刻
  • 復元によって失われる可能性がある更新
  • 作業中に停止する投稿・受付・編集
  • 復元前の現状バックアップと切り戻し条件
05

5. 本番を壊さない場所で復元を試す

初めての復元操作を障害中の本番サイトで試すと、原因を増やすおそれがあります。提供サービスの復元方法を読み、テスト用ドメイン、ステージング環境、または本番と分離した場所へコピーして、バックアップを展開できるか確認します。

テストではトップページだけでなく、代表記事、画像、ログイン、検索、フォーム、スマートフォン表示まで確認します。外部通知や決済へ接続している機能は、誤送信や重複処理を起こさない試験方法を決めてから操作します。

  • 本番と分離した復元先を用意した
  • 代表的なページと画像を開いた
  • 管理画面で保存操作を確認した
  • フォームや外部連携を安全な宛先で試した
06

6. 成功を再現できる記録に残す

復元テストの記録には、バックアップの日付、対象、取得元、復元先、開始時刻、終了時刻、確認したURLや機能を残します。『復元できた』という一文だけでなく、次の担当者が同じ順番で操作できる程度の具体性を持たせます。

バックアップファイルが開けたこと、データベースが読み込めたこと、サイトへログインできたことなど、観測できた事実を分けて記録します。失敗した場合もエラーと未確認項目を残し、保管や手順を直した後に再テストします。

  • 対象バックアップの日時と保存場所
  • 操作した担当者と使用した公式手順
  • 確認できたページ・機能・管理画面
  • 失敗した項目と次回の再テスト日
07

7. 定期点検を担当者変更とセットにする

復元手順は、サーバーの画面、WordPressの構成、担当者が変わると古くなります。四半期や半期など無理なく続く周期を決め、バックアップの作成日時、保存先の空き容量、管理者権限、公式手順の変更を点検します。

担当者が退職・休職したときに復旧できない状態を避けるため、引き継ぎ時には読み合わせだけでなく、別の担当者がテスト環境へ復元できるか確かめます。サービス選びでも、保存日数の数字だけでなく、自社の担当者が取得と復元を再現できるかを比較します。

  • 次の点検日と責任者を決めた
  • 管理アカウントと二段階認証を引き継げる
  • 保管先の容量と保存期限を確認した
  • 別の担当者が復元手順を再現できた