AWS Backupと災害対策のシナリオ判断

バックアップの取得から災害後の再開まで、目標と実績を比較します。時刻・所要時間・対象選択を具体化し、コピーやGatewayの設置だけでは完了しない準備をシナリオから判断します。

この単元で学ぶこと

RPO・RTOを数値で評価する
保護対象・コピー・権限と復元の条件を確認する
Gatewayの役割と業務復旧の検証を区別する

本文解説

1. 目標を二つに分ける受注システムのRPOが10分、RTOが60分なら、失ってよい更新の時間幅と再開までの時間を別々に評価します。例えば障害が14時、最新復元点が13時55分、業務再開が14時45分なら、5分と45分で両目標の範囲です。取得頻度だけを見たり、復元時間をRPOと呼んだりしないようにします。

2. 予定と成功の違い 5分間隔の取得予定でも、連続してジョブが失敗していれば実際の最新復元点は古くなります。プランの画面だけで目標達成と判断せず、成功した取得やコピーの時刻と障害発生時刻を比べます。監視で失敗を見つけ、対象や権限、容量等の原因を調べます。

3. 取得対象を確かめる本番DBをタグでプランへ含める場合、タグの値を変更すると対象選択の条件から外れるおそれがあります。プランの存在だけで全資源を保護したと考えず、割当てと実行状況を確認します。新しい資源や別のデータ領域が追加されたときも、対応する機能と必要な保護が適用されるかを確認します。

4. コピー先でも復元できるか別アカウントや別リージョンにコピーがあっても、復元に使う権限や鍵、接続先の準備が不十分なら業務は再開できません。暗号化データへのアクセス、復元先のネットワーク、アプリの接続情報等を確認します。障害時に使えない元環境の担当者だけが手順を知っている状態も避け、必要な情報と役割を準備します。

5. 高可用性と過去の正常時点待機系へ最新の変更を反映する構成は、機器故障等への切替を速める用途です。しかし、誤って注文を削除した変更も反映される場合があるため、過去の正常時点へ戻す保護とは区別します。保存世代、復元可能な時点、業務上の整合性を考え、可用性とバックアップの両方を評価します。

6. 復元時間の内訳検知10分、復元35分、接続切替5分、業務確認15分を順に行うと合計65分です。RTO60分なら5分超過します。データを戻した時点だけを復旧完了とすると、利用者が使えない時間を見落とします。実測した結果からどの段階を短縮すべきかを考え、確認を省くことで数字だけを達成しないようにします。

7. ハイブリッドの保存経路オンプレミスのアプリがバックアップファイルをNFS/SMBへ出力し、S3 File GatewayでS3へ保存する構成を考えます。ローカルへ書いたことと、クラウドへアップロードできたことを区別します。通信が途切れた際の未転送分、キャッシュ容量、クラウド上の保持・アクセス制御を確認します。Gatewayは復元試験の代わりではありません。

8. 試験の成功範囲を残す復元テストでは資源を起動できたかに加え、業務データを読み、必要な取引や整合性を確認します。試験で使った復元点、条件、所要時間を記録します。別リージョン災害や権限障害を試していないなら、その条件まで達成済みと広げません。試験用資源の削除と料金を確認し、定期的な見直しへつなげます。

図解

二つの時間軸で目標を確認する — 図はRPO10分・RTO60分の例です。復元点の新しさと再開の速さは別の条件です。

重要ポイント

予定した頻度ではなく利用可能な復元点を使って評価する。
復旧時間には検知・切替・業務確認も含める。
コピーの存在、復元可能性、業務再開を順に確認する。

間違えやすい点

最新の待機系があれば過去の誤削除にも必ず戻せると考える。
ローカルへの書込み成功をクラウド上の復元点完成と同一視する。

用語解説

復旧時間の内訳: 検知、復元、切替、確認等、業務再開までの工程ごとの所要時間。
保護対象の割当て: 資源をバックアップ方針の対象へ明示・条件指定等で含めること。
復元検証: 復元の成否だけでなく必要なデータや業務が利用可能かを確かめること。

参考資料

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

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