イベントサイトのバックアップ復元テスト用チェックリスト
バックアップがあるだけでは復旧できる証拠になりません。チケット販売前に公開サイトと分離した環境へ復元し、訪問者の動線を試します。実際の参加者情報や決済は演習に使いません。
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目標/データ差 | ________ / ________ |
| 問題、担当、再試験 | ________ |
記録は復元対象サイトの外に保存し、大きな変更後にも繰り返します。
出典と参考資料
- Website Backup Restore Testing Checklistmybox.com · 確認日
- Perform periodic recovery testingAWS Well-Architected Framework · 確認日
- Define recovery objectives for downtime and data lossAWS Well-Architected Framework · 確認日
- Backing up your databaseWordPress Developer Resources · 確認日