RPOは受け入れる用意のあるデータ損失ウィンドウを表し、RTOは収めることを目指す中断時間を表します。有用な業務機能に対して両方を定義し、演習で復旧手順を証明します。バックアップスケジュールやサーバー仕様だけでは、どちらの目標も確立されません。
人が使えるサービスから始める
復旧目標は、孤立したマシンではなく業務機能を表すときに有用になります。サーバーが起動しても、顧客がサインインできず、ファイルを取得できず、リクエストを完了できないことがあります。終了条件を平易な言葉で書きます。承認されたユーザーがアプリケーションにアクセスでき、必要なデータが整合していることです。これにより、インフラチーム以外の人でも目標をテストできます。
アプリケーションの所有者に、中断が何を妨げるか、データ欠落が何のコストになるかを尋ねます。週次出版物とトランザクション処理アプリケーションでは答えが異なることがあります。結果として得られる目標は、ハードウェアカタログから作られた約束ではなく、計画目標として扱います。誰が承認したか、計画がどの障害シナリオを対象とするかを記録します。
2つの時計を分離する
RPOは、復旧したデータが障害時点からどれだけ前までよいかに関係します。RTOは、機能がどれだけ利用不能のままでよいかに関係します。最近のバックアップはデータ損失ウィンドウを改善できますが、復元が遅ければ復旧時間目標を逃します。逆に、高速な再起動は最新データが残っていないアプリケーションへのアクセスを復元することがあります。
基準点を指定します。インシデントの時計がいつ始まるか、何をもって運用復旧とするか、使用可能なデータポイントをどう特定するかを決めます。目標は測定結果とは分けておきます。目標は目指すものであり、演習は現在のプロセスが達成したものを示します。アプリケーションやデータセットが変わったら、どちらも見直します。
復旧の各ステップを予算化する
実用的なRTO予算には、検知、評価、承認、復旧環境へのアクセス、復元、アプリケーション検証、再開が含まれます。ファイルコピー時間は構成要素の1つにすぎません。復旧鍵を持つ人が対応できない場合、理論上は高速なバックアップでも使えないことがあります。依存関係を列挙し、検討中の障害時に復旧チームがそれらに到達できるようにします。
各ステップに暫定時間を割り当て、その後で見積もりを観察に置き換えます。この例示的な2時間予算では、復元に最大の余裕を割り当てつつ、検証にも保護された時間があります。数値は計画例を表し、SwissOctetのサービス提供を表すものではありません。合計に余裕がなければ、目標が信頼できるものになる前に設計を改善する必要があります。
| 復旧ステップ | 例示的な割り当て | 収集する証拠 |
|---|---|---|
| 検知と評価 | 15分 | アラート到着とインシデント判断 |
| 復旧環境を準備する | 20分 | アクセスと設定が利用可能 |
| データとサービスを復元する | 50分 | 整合したデータで復元完了 |
| 検証して再開する | 25分 | ユーザージャーニーが成功 |
| 予備マージン | 10分 | 予期しない作業を記録 |
実際のデータ損失ウィンドウを確認する
毎時スケジュールされたジョブが自動的に1時間のRPOを提供するわけではありません。ジョブの失敗、アップロードの遅延、使用不能なコピーにより、最新の復旧可能ポイントがはるかに古くなることがあります。正常完了と実際に復元できる状態を観察します。複数のデータストアを持つアプリケーションでは、各タイムスタンプを個別に読むのではなく、復旧ポイントが互換していることを確認します。
演習中に基準イベントを選びます。たとえば既知の時刻に作成された承認済みテストレコードです。復元後、最新の有効なレコードを特定し、ギャップを測定します。無害なテストデータを使います。これにより実用的な結果が得られ、ジョブ成功だけを示すダッシュボードでは隠れていた可能性のある前提が明らかになります。
予算内で戦略を選ぶ
バックアップと復元、準備済みスタンバイ環境、レプリケーションされたアプリケーション設計は、コストと複雑さを復旧速度と引き換えにします。レプリケーションは一部の遅延を減らせますが、偶発的な削除やアプリケーションの誤りも再現することがあります。稼働設定から乖離したスタンバイは独自のリスクを生みます。文書化した障害シナリオと目標に対して戦略を選びます。
4時間の目標を持つ小規模サービスと、演習で復元だけで6時間かかる大規模データセットを考えます。より高速なネットワークポートを買うことは仮説にすぎません。ストレージ読み取り、受信書き込み、アプリケーション復旧が支配的かもしれません。測定された制限ステップを改善するか、復旧セットを減らすか、戦略を変えてから、再度演習します。
本番を危険にさらさずに演習する
分離された復旧環境と定義された演習時間枠を使います。復元されたジョブが実際の通知を送信したり、公開支払いを受け付けたり、本番連携に書き込んだりできないようにします。演習を完了と見なす前に、アクセス、データ整合性、代表的なユーザージャーニーをテストします。元の手順を書いていない人を含め、不足している指示を明らかにします。
演習のタイムライン、達成した復旧ポイント、利用できない情報によって生じたすべての中断を記録します。有用なレポートは、測定結果、目標とのギャップ、具体的な是正措置を示します。意味のある変更後、およびプロジェクトの重要性に適した間隔で繰り返します。
障害時にも計画を使える状態に保つ
復旧手順は、失敗したアプリケーションだけに依存せずチームがアクセスできる場所に保管します。資格情報と暗号化鍵は、テスト済みのアクセスプロセスを備えた保護された場所に保管します。プロジェクトの進展に合わせて、連絡先、データセットサイズ、依存関係を更新します。古くなった計画は、復元が始まる前に時間的余裕を消費することがあります。
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による編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。