RTO・RPOとバックアップ設計の全体像

復旧計画では「いつまでに動くか」と「どこまでのデータを戻すか」を別々に決めます。RTO・RPOから保存、複製、復元試験までの全体像をつかみます。

この単元で学ぶこと

1. 二つの損失システム停止では、使えない時間による損失と、戻せないデータによる損失が起こります。営業サイトが30分止まる問題と、直前30分の注文が消える問題は同じではありません。前者の目標をRTO、後者の許容範囲をRPOで表し、業務担当者と別々に決めます。

2. 時間軸で読む 10時に障害が起き、10時30分に業務が再開し、復元データが9時55分までの状態なら、停止は30分、失われ得る更新範囲は5分です。RTOが40分、RPOが10分ならこの例は両方の範囲内です。復元作業が速くてもデータが前日までなら、時間の目標だけを達成する場合があります。

3. 目標と実績 RTO・RPOは目標であって、バックアップ設定に書くだけで保証される値ではありません。実績は訓練や障害の時刻と回復したデータから測ります。目標を超えた場合は、停止時間のどの工程が長いか、復旧点がなぜ古いかを分けて改善します。

4. 保存と複製定期バックアップは過去の復旧点を残します。レプリケーションは別の保存先へ変更を継続反映し、新しいデータを用意する助けになります。ただし誤更新も複製され得るため、複製だけで過去へ戻れるとは限りません。最新状態への切替と正常な過去への復元を組み合わせます。

5. 環境の準備度データが最新でも、復旧先のネットワークやアプリを一から作ると時間がかかります。構成のコード化、事前配置、起動手順、自動化をRTOに合わせて選びます。待機系の常時費用を増やすと準備時間を減らせる場合がありますが、不要な厳しさまで追求せず業務要件と費用を比較します。

6. 何を残すか業務データだけでなく、アプリのバージョン、構成、鍵や証明書、認証先への接続も棚卸しします。保持期間は何日前の状態まで戻る必要があるか、取得頻度はどれだけ細かい復旧点が必要かの判断です。暗号化データを復元するための鍵と権限を失わないことも条件です。

7. 検証と監視バックアップジョブ成功は、アプリが正常に戻る証拠ではありません。実際に復元し、データ整合性、利用者接続、必要な業務操作を確認します。平常時にはバックアップ失敗と複製遅延を監視します。定期試験で得た実績を目標へ照合し、データ量の増加や構成変更後も更新します。

8. 障害範囲と手順同じAZ内のコピーではAZ障害、同じアカウントの管理下だけでは権限事故への耐性が不足する場合があります。対象事象を決めて保存先や権限を分離します。誰が切替を開始し、どの順序で戻し、いつ業務完了とするかを書いた手順書を、障害時にも読める場所へ保管します。

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

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