RTO・RPOとバックアップ設計のシナリオ判断

この単元で学ぶこと

• 具体的な時刻から停止と損失を算出する
• 未達の原因に対応した復旧策を選ぶ
• 実運用のバックアップと復旧試験を設計する

本文解説

1. 通販障害の採点 注文サービスの目標をRTO30分・RPO10分とします。14時に停止し14時25分に注文確認まで再開、データは13時55分まで戻ったなら、停止25分・損失範囲5分で両方を満たします。報告書にはサーバー起動時刻だけでなく、注文確認完了と最後の復元注文の時点を残します。

2. 速いが古い復旧 別の訓練で14時10分に再開できても、データが13時30分までならRPO未達です。アプリの起動をさらに速くしても主問題は解決しません。バックアップ成功状況、コピーの完了、継続複製の遅れを調べ、使える復旧点を新しくする方策を選びます。

3. 新しいが遅い復旧 データは13時59分まで戻る一方、再開が14時45分ならRTO未達です。検知、担当者の判断、復元、鍵の権限取得、DNS変更、業務確認を分解します。手作業の自動化や事前準備で時間を減らし、取得頻度の増加だけに投資しないようにします。

4. 定期バックアップの失敗 15分ごとの計画でも、10時45分の取得が失敗し最後に使える点が10時30分なら、10時50分障害で20分の更新が失われ得ます。RPO15分を満たしたとはいえません。失敗通知と再試行の運用、復旧点の最新性監視が必要で、計画表だけを確認する監査では不足します。

5. 復旧先のアクセス障害 別リージョンのバックアップはあるが、復旧用ロールに鍵の使用権限がなく復元が止まるケースがあります。保存が成功したことと、その主体が災害時に復元できることは別です。訓練では実際の復旧用ロールを使い、暗号鍵、ネットワーク、外部認証まで確認します。

6. 誤削除の影響範囲 担当者の誤削除がレプリカへ伝わった場合は、消える前の正常な点へ復元します。バックアップも同じ権限で削除できるなら、権限分離やロック等を見直します。関連する注文と在庫を同時に整合する状態へ戻し、その後の正当な更新を再適用できるかも計画します。

7. 復旧能力が変化する 年初は30分で復元できたデータが、年末には増えて60分かかることがあります。実データ量に近い試験を続け、復元方法や待機方式を見直します。訓練で本番通知や決済を誤送信しないよう環境を分離しつつ、必要な業務確認が省略されないようにします。

8. 改善案の報告 「DRを導入した」ではなく、対象事象、目標値、停止実績、データ時点、未達工程、改善後の再試験を示します。切替だけでなく復旧先で増えたデータを元へ戻す手順も評価します。目標の変更は技術側の都合だけで決めず、業務への影響と合意を伴わせます。

図解

重要ポイント

• 障害前の復旧点と障害後の再開時刻を取り違えない
• 古いデータには取得・複製、遅い再開には工程改善を行う
• 復旧用権限と現実のデータ量で試験する

間違えやすい点

• ジョブが予定されていたことを成功の証拠にしない
• 本番と異なる強い権限で試しただけで復旧可能としない
• データ量が増えても過去の試験結果を永久に使わない

用語解説

利用可能な復旧点

必要な場所と権限で実際に復元へ使える保存状態。

復旧実績

試験や実障害で得た停止時間と回復データの時点などの記録。

再試験

改善後に同じ目標と条件で実装が要件を満たすか確認すること。

関連教材

• RTO・RPOとバックアップ設計の違いと使い分け
• RPOとバックアップ設計を理解する