RPOとバックアップ設計を理解する

RPOは保存データの新しさに関する目標です。予定したバックアップ頻度と、実際に復元できる最新時点の差を見分け、失敗・遅延・破損を含めて設計します。

この単元で学ぶこと

  • 復旧点と障害時刻から損失範囲を計算する
  • 取得頻度・保持・複製を使い分ける
  • 利用可能で整合したバックアップを保護する

本文解説

1. 復旧点から測る 12時の障害で11時50分までのデータが復元できるなら、直前10分の更新が未回復となり得ます。これが実際のデータ損失の時間範囲です。RPO5分なら未達です。復元作業に何分かかったかではなく、回復できたデータがいつまでの状態を含むかを確認します。

2. 取得予定と成功実績 15分間隔のバックアップでも直近のジョブが失敗すれば、使える復旧点は30分以上前になる可能性があります。コピー先への転送が未完了の場合も、元側の成功だけでは遠隔復旧に使えません。スケジュール、完了時刻、復旧点が表すデータ時点を区別して監視します。

3. 複製と遅延 変更を継続反映するレプリケーションや対応する継続バックアップは、小さいRPOを目指す手段になります。ただし通信遅延や停止、サービスの特性により、復旧先に最後の書込みまで届いていないことがあります。非同期複製を採用しただけでRPOゼロとせず、ラグと回復できる時点を確認します。

4. 保持期間の役割 取得頻度は復旧点の細かさ、保持期間は戻れる過去の長さです。毎分取得していても1日で消すなら、3日前に始まったデータ破損へ戻れません。30日保持していても1日1回だけなら、直近5分のRPOをそれだけで満たせません。両方を独立した要件として決めます。

5. 正常なデータ時点 最も新しい復旧点に不正な更新が含まれる場合、より前の正常な点を選ぶ必要があります。その場合に失われる正当な更新も評価し、他の記録から再適用できるかを検討します。複数DBの注文と在庫を別々の不整合な時点へ戻さないよう、整合性を取る取得・復元手順を用意します。

6. 独立した保存先 AZやリージョンの障害に備えるなら、その範囲から独立した復旧点が必要です。管理者の誤操作や認証侵害への備えでは、権限分離や保存ロック等も検討します。資源ごとにコピー・保持・ロックの対応が異なるため、採用するAWS Backup等の現在の機能を確認します。

7. 鍵とアクセス 暗号化バックアップを保存していても、復元先に鍵の利用権限がない、鍵が削除された、といった状態では復元できません。暗号鍵のライフサイクルをデータ保持と合わせ、復旧用IAMロールで実際に復元を試します。保存先を別にする場合にはクロスアカウントやリージョンの条件も確かめます。

8. 復元で確かめる バックアップのサイズやジョブ成功表示だけを合格根拠にしません。別環境へ復元し、期待する最後の注文IDや時刻、関連DBの整合性を調べます。RPO5分を狙うなら、どの障害時点でも必要な復旧点が使えるかを継続監視し、失敗や複製遅延を早く発見する必要があります。

図解

予定と使える復旧点
スケジュールではなく実際に利用可能な復旧点で判定します。

重要ポイント

  • RPOは障害時刻と回復可能なデータ時点の差で検証する
  • 取得頻度と保持期間は別
  • 成功した復旧点・コピー完了・鍵と整合性を確認する

間違えやすい点

  • 予定間隔を達成済みRPOとして報告しない
  • 非同期複製をRPOゼロの保証としない
  • 最新の復旧点が常に正常とは限らない

用語解説

復旧点
データを戻すことのできる保存状態や時点。
複製ラグ
元で確定した変更が複製先へ反映されるまでの遅れ。
保持期間
取得した復旧点を削除せず保存する期間。取得間隔とは別。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。