# RPOとRTOをテスト可能な復旧予算に変える | SwissOctet Insights https://swissoctet.com/ja/insights/rpo-rto-recovery-budget/ SwissOctet / インサイト / 2日目の運用 2日目の運用 応用 · 4分で読めます RPOとRTOをテスト可能なリカバリ予算に変える 許容できるデータ損失と中断を、依存関係、復元容量、測定可能な演習を含む時間ベースのリカバリ計画に変換してください。 SwissOctet編集部 ガイドを保存 リンクをコピー このページの内容 01 人が使えるサービスから始める 02 2つの時計を分離する 03 復旧の各ステップを予算化する 04 実際のデータ損失ウィンドウを確認する 05 予算内で戦略を選ぶ 06 本番を危険にさらさずに演習する 07 障害時にも計画を使える状態に保つ 実践チェックリスト 出典と参考資料 ライブラリに戻る 直接の答え RPOは受け入れる用意のあるデータ損失ウィンドウを表し、RTOは収めることを目指す中断時間を表します。有用な業務機能に対して両方を定義し、演習で復旧手順を証明します。バックアップスケジュールやサーバー仕様だけでは、どちらの目標も確立されません。 01 人が使えるサービスから始める 復旧目標は、孤立したマシンではなく業務機能を表すときに有用になります。サーバーが起動しても、顧客がサインインできず、ファイルを取得できず、リクエストを完了できないことがあります。終了条件を平易な言葉で書きます。承認されたユーザーがアプリケーションにアクセスでき、必要なデータが整合していることです。これにより、インフラチーム以外の人でも目標をテストできます。 アプリケーションの所有者に、中断が何を妨げるか、データ欠落が何のコストになるかを尋ねます。週次出版物とトランザクション処理アプリケーションでは答えが異なることがあります。結果として得られる目標は、ハードウェアカタログから作られた約束ではなく、計画目標として扱います。誰が承認したか、計画がどの障害シナリオを対象とするかを記録します。 02 2つの時計を分離する RPOは、復旧したデータが障害時点からどれだけ前までよいかに関係します。RTOは、機能がどれだけ利用不能のままでよいかに関係します。最近のバックアップはデータ損失ウィンドウを改善できますが、復元が遅ければ復旧時間目標を逃します。逆に、高速な再起動は最新データが残っていないアプリケーションへのアクセスを復元することがあります。 基準点を指定します。インシデントの時計がいつ始まるか、何をもって運用復旧とするか、使用可能なデータポイントをどう特定するかを決めます。目標は測定結果とは分けておきます。目標は目指すものであり、演習は現在のプロセスが達成したものを示します。アプリケーションやデータセットが変わったら、どちらも見直します。 03 復旧の各ステップを予算化する 実用的なRTO予算には、検知、評価、承認、復旧環境へのアクセス、復元、アプリケーション検証、再開が含まれます。ファイルコピー時間は構成要素の1つにすぎません。復旧鍵を持つ人が対応できない場合、理論上は高速なバックアップでも使えないことがあります。依存関係を列挙し、検討中の障害時に復旧チームがそれらに到達できるようにします。 各ステップに暫定時間を割り当て、その後で見積もりを観察に置き換えます。この例示的な2時間予算では、復元に最大の余裕を割り当てつつ、検証にも保護された時間があります。数値は計画例を表し、SwissOctetのサービス提供を表すものではありません。合計に余裕がなければ、目標が信頼できるものになる前に設計を改善する必要があります。 復旧ステップ 例示的な割り当て 収集する証拠 検知と評価 15分 アラート到着とインシデント判断 復旧環境を準備する 20分 アクセスと設定が利用可能 データとサービスを復元する 50分 整合したデータで復元完了 検証して再開する 25分 ユーザージャーニーが成功 予備マージン 10分 予期しない作業を記録 04 実際のデータ損失ウィンドウを確認する 毎時スケジュールされたジョブが自動的に1時間のRPOを提供するわけではありません。ジョブの失敗、アップロードの遅延、使用不能なコピーにより、最新の復旧可能ポイントがはるかに古くなることがあります。正常完了と実際に復元できる状態を観察します。複数のデータストアを持つアプリケーションでは、各タイムスタンプを個別に読むのではなく、復旧ポイントが互換していることを確認します。 演習中に基準イベントを選びます。たとえば既知の時刻に作成された承認済みテストレコードです。復元後、最新の有効なレコードを特定し、ギャップを測定します。無害なテストデータを使います。これにより実用的な結果が得られ、ジョブ成功だけを示すダッシュボードでは隠れていた可能性のある前提が明らかになります。 05 予算内で戦略を選ぶ バックアップと復元、準備済みスタンバイ環境、レプリケーションされたアプリケーション設計は、コストと複雑さを復旧速度と引き換えにします。レプリケーションは一部の遅延を減らせますが、偶発的な削除やアプリケーションの誤りも再現することがあります。稼働設定から乖離したスタンバイは独自のリスクを生みます。文書化した障害シナリオと目標に対して戦略を選びます。 4時間の目標を持つ小規模サービスと、演習で復元だけで6時間かかる大規模データセットを考えます。より高速なネットワークポートを買うことは仮説にすぎません。ストレージ読み取り、受信書き込み、アプリケーション復旧が支配的かもしれません。測定された制限ステップを改善するか、復旧セットを減らすか、戦略を変えてから、再度演習します。 06 本番を危険にさらさずに演習する 分離された復旧環境と定義された演習時間枠を使います。復元されたジョブが実際の通知を送信したり、公開支払いを受け付けたり、本番連携に書き込んだりできないようにします。演習を完了と見なす前に、アクセス、データ整合性、代表的なユーザージャーニーをテストします。元の手順を書いていない人を含め、不足している指示を明らかにします。 演習のタイムライン、達成した復旧ポイント、利用できない情報によって生じたすべての中断を記録します。有用なレポートは、測定結果、目標とのギャップ、具体的な是正措置を示します。意味のある変更後、およびプロジェクトの重要性に適した間隔で繰り返します。 07 障害時にも計画を使える状態に保つ 復旧手順は、失敗したアプリケーションだけに依存せずチームがアクセスできる場所に保管します。資格情報と暗号化鍵は、テスト済みのアクセスプロセスを備えた保護された場所に保管します。プロジェクトの進展に合わせて、連絡先、データセットサイズ、依存関係を更新します。古くなった計画は、復元が始まる前に時間的余裕を消費することがあります。 SwissOctet構成を比較するときは、復旧アーキテクチャとカタログの任意のバックアップ選択肢を分けて考えます。オプションが何を対象とし、復旧データがどこに保持され、誰が復元を行うかを確認します。カタログはアプリケーションのRPOやRTOを確立しません。測定されたプロセスと実際のサービス条件が、その判断の基礎を提供します。 行動に移す 実践チェックリスト。 ✓ 復旧された業務機能を定義する。 ✓ RPOとRTOの目標を別々に承認する。 ✓ 検知、アクセス、復元、検証を予算化する。 ✓ 最新の使用可能なデータポイントを測定する。 ✓ 分離された環境で演習する。 ✓ ギャップを記録し、関連する変更後に繰り返す。 チェックリストをダウンロード よくある質問 重要な詳細。 RTOは稼働時間と同じか？ + いいえ。RTOは中断シナリオに対する復旧目標です。稼働時間は一定期間の可用性を測定します。一方が他方を確立するものではありません。 毎時バックアップは1時間のRPOを保証するか？ + いいえ。完了した使用可能なコピーとアプリケーションの整合性要件を確認してください。ジョブの失敗や転送遅延は、復旧可能なデータのギャップを広げることがあります。 すべてのプロジェクトでスタンバイサーバーを使う必要があるか？ + プロジェクトの復旧目標と測定された復元プロセスに対して戦略を選びます。スタンバイはコストと運用の複雑さを追加し、自動的に必要なものではありません。 主要参考文献 出典へ。 これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。 NIST SP 800-34 Rev. 1: コンティンジェンシープランニングガイド nvlpubs.nist.gov AWS Well-Architected: 復旧目標を定義する docs.aws.amazon.com Microsoft Learn: ビジネス継続性、高可用性、ディザスターリカバリー learn.microsoft.com SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。 知識をつなぐ 関連インフラ。 Vector VPS スイス Vault Storage スイス Metal Atlas スイス スレッドを維持 次のフィールドノート。 すべてのガイドを探索 フィールドノート / 01 + 2日目の運用 応用 実際に復元できるバックアップを構築する 復旧目標を選択し、独立したコピーを保護し、インシデントが問題を強制する前に復元を練習してください。 4分で読めます ガイドを読む フィールドノート / 02 + 2日目の運用 応用 ホストされたプロジェクトのための実践的な脅威モデル 資産と信頼境界をマッピングし、いくつかの現実的な障害シナリオを選択して、テスト可能な制御に変換しましょう。 6 分で読めます ガイドを読む フィールドノート / 03 + 2日目の運用 応用 アクセスを失わずに安全なWindows RDP管理を行う ネットワーク到達性、認証、特権を分離し、リモートアクセスを厳格化する前に復旧経路を検証しましょう。 6 分で読めます ガイドを読む