メインコンテンツへ移動
Boletolibre

イベントサイトのバックアップ復元テスト用チェックリスト

バックアップがあるだけでは復旧できる証拠になりません。チケット販売前に公開サイトと分離した環境へ復元し、訪問者の動線を試します。実際の参加者情報や決済は演習に使いません。

Boletolibre編集部

公開日

バックアップから隔離環境への復元、動線の確認、復旧目標との比較を示すオリジナル図。
必要な訪問者の動線が動き、結果を記録して演習を終えます。

1. 範囲と目標を決める

バックアップ時刻とタイムゾーン、担当者、重要な訪問者の動線を記します。RTOは許容できる最大の停止時間、RPOは時間で表す許容データ損失です。イベントに合う目標を決め、実測値と比較します。バックアップ成功だけでは復旧能力を証明できません。[3][2]

記録項目内容
重要な動線イベントページ→申込・チケット→安全な確認
復元時点日時、タイムゾーン、保存場所
RTO・RPO目標チームが承認した限度
環境本番DNSを変更しない隔離テスト環境

2. バックアップの対象を確認する

ページとDB、ファイルと画像、設定と秘密情報を分けて確認します。例えばWordPressのDBバックアップにはファイル、テーマ、プラグイン、アップロード、設定ファイルは含まれません。外部のチケット・メールサービスの記録には別の復旧計画が必要です。[4]

  • 各データの原本と復旧担当者を記す。
  • 本番のDNSを切り替えず、DNSと証明書の手順を記録する。
  • 試していない外部サービスは「未試験」と明示する。

3. 本番に影響を与えず復元する

  • アクセスを制限したテスト環境を用意し、開始時刻を記録する。
  • メール、Webhook、解析、実決済を無効化またはテスト先に向け、架空のデータを使う。
  • ファイル、DB、画像、設定を復元し、手作業や不足を記録する。
  • 本番サイトとDNSを変更しない。

参考チェックリストも隔離した環境でファイル、DB、フォーム、連携を確認するよう勧めています。[1]

4. 訪問者の動線を試す

確認証拠
イベントページ復元時点の日時、会場、価格、規約
画像とリンク画像、資料、チケットリンク
申込架空の申込がテスト先にだけ届く
購入と通知テストモードで実請求・実参加者への通知なし
管理権限者のログインと無害な変更

各項目を合格、不合格、未試験で記録します。トップページが表示されても申込の復旧は証明できません。

5. 測定して再試験する

合意した動線が動くまでを復旧時間として測り、RTOと比べます。復元データの時刻差をRPOと比べます。重要な失敗には担当者と再試験日を割り当てます。[2][3]

演習記録記入欄
日付、担当、環境________
バックアップと復元時点________
RTO目標/実測時間________ / ________
RPO目標/データ差________ / ________
問題、担当、再試験________

記録は復元対象サイトの外に保存し、大きな変更後にも繰り返します。

出典と参考資料

  1. Website Backup Restore Testing Checklistmybox.com · 確認日
  2. Perform periodic recovery testingAWS Well-Architected Framework · 確認日
  3. Define recovery objectives for downtime and data lossAWS Well-Architected Framework · 確認日
  4. Backing up your databaseWordPress Developer Resources · 確認日