目標復旧時間（RTO）と目標復旧時点（RPO）は、ソフトウェア停止を許容できる時間と、バックアップ間隔を測定する指標です。
- RTO：アプリケーションの停止によって事業運営に甚大な被害が生じるまでの最大時間。
- RPO：企業が業務上または財務上の重大な影響を受けるまでに許容できるデータ損失量。
RTOとRPOは合わせて、ディザスタリカバリや事業継続手順に役立つツールであり、バックアップ要件を厳密に追跡する必要がある組織には欠かせません。本記事では、両方の指標、その違い、ユースケースを詳しく解説します。
RTOとRPOの比較表
以下の表は、目標復旧時間と目標復旧時点の違いを一覧で示したものです。
| 特性 | 測定対象 | 変動要因 | 考慮すべき事項 |
|---|---|---|---|
| RTO | 秒、分、時間、日、および事業運営の復旧に必要な手順 | 侵害を受けたアプリケーションの重要度 | 予想される平均ダウンタイムコスト 問題を抑えるために必要な復旧速度 |
| RPO | 失われるデータ量 | バックアップスケジュールの頻度 | 組織が許容できるデータ損失量 既存のバックアップスケジュールの頻度と網羅性 |
RPOとRTOの仕組み
組織のITリーダーは、事業影響分析（BIA）を実施してRPOとRTOの値を特定し、災害や重大なエラー、その他の緊急事態によって重要なアプリケーションやプロセスが中断した場合に、どのような影響が生じる可能性があるかを判断します。
BIAの結果は、企業が利用する業務アプリケーションの種類、収集・保存するデータの性質、発生する可能性のある緊急事態の種類などによって異なります。関連する災害には次のようなものがあります。
- データ保管施設に影響を及ぼす暴風雨や洪水
- 重要なアプリケーションに感染するコンピューターウイルス
- ファイルへのアクセスを制限するランサムウェア攻撃
- 悪意ある内部関係者によるデータ窃盗
- サードパーティー製アプリケーションの停止
企業はRPOとRTOを連続的な指標として表現し、いずれも目標として捉えることができます。ただし、この類似点を除けば、必要な計算を行う際には根本的な違いがあります。
目標復旧時間（RTO）の仕組み
組織の目標復旧時間は、アプリケーションが停止しても事業に重大な損害を与えずに済む許容停止時間を示します。大きな影響なく数日間停止できるアプリケーションもあれば、優先度の高いアプリケーションは数秒停止しただけで顧客の不満を招き、ビジネスの損失につながる場合もあります。
RTOの算出
RTOを算出する際、企業は利用可能なリソースや選択肢に基づき、アプリケーションを優先度と潜在的損失によって分類する必要があります。例えば、RTOをほぼゼロにする標準計画にはフェイルオーバーサービスが必要ですが、RTOを4時間とする場合は、ベアメタル復元から始め、アプリケーションとデータを完全に利用可能にするオンプレミス復旧が可能です。
IT部門が優先度の高いアプリケーション向けにフェイルオーバーサービスへ投資していれば、RTOを秒単位で安全に設定できます。フェイルオーバーサービスは、サーバーやプラットフォームが停止すると別のサーバーやプラットフォームへ自動的に切り替えます。IT部門は引き続きオンプレミス環境を復旧する必要がありますが、アプリケーションがクラウド上で処理されるため、復旧にかけられる時間は長くなります。
RTO算出時に確認すべき質問
RTOは通常、アプリケーションとその機能によって異なります。多くの意思決定者は、次の質問を通じて重要なRTOを算出しやすくなります。
- 顧客向けに常時利用可能である必要があるアプリケーションはどれか。
- 企業の収益業務を機能させるために利用可能でなければならないアプリケーションはどれか。
- 最前線のセキュリティを担うアプリケーションがあるか。
- 企業の重要なアプリケーションは、どのデータストアに保存されているか。
- ユーザー体験に悪影響が出るまで、アプリケーションはどのくらい停止できるか。
- 停止後、必要なアプリケーションの機能を復旧する一般的な所要時間はどのくらいか。
- 既存のバックアップからアプリケーションの失われたデータを復元できるか。
- このアプリケーションは、企業が目標を達成するうえでどのように役立つか。
RTO達成のベストプラクティス
RTOはさまざまな変数に左右されますが、以下の原則により、組織はRTOの目標に近づくことができます。
現実的に考え、改善の余地を認識する
まずは現実的な期待値を設定します。それでもRTOの達成が難しいと分かる場合があります。そのようなときは、弱点となりそうな箇所を見つけるのが実践的な対応です。
例えば、企業の人員が不足しており、全従業員が作業に取り組んでも、チームがアプリケーションの機能復旧に苦戦し続けることがあります。この場合、増員が最も適切な選択肢かもしれません。
既存のバックアップテクノロジーを検証する
自社の現在のバックアップソリューションを見直し、目標を満たしていなければ、より優れた代替策への投資を検討します。特に、従来型のバックアップソリューションを使用していて、RTOの目標を継続的に達成できていない場合は重要です。更新されたバックアップまたはディザスタリカバリプラットフォームに投資することで、企業は望ましいRTOを達成しやすくなります。
必要に応じてアプリケーションコードを更新する
アプリケーションの問題がバグや古いコードに起因するものか調査します。そうであれば、問題に対処することで停止回数とダウンタイムを減らせる可能性があります。
リアルタイム通知を利用する
アプリケーションにパフォーマンス上の問題が発生した際に即座にフィードバックを提供するリアルタイムアラートを設定するか、適切なプラットフォームやデバイスで担当者が通知を受け取れるようツールを設定します。
低RTOが必要なアプリケーションを特定する
低いRTOを設定するアプリケーションを厳選します。すべての企業アプリケーションについて数時間ごとにバックアップを作成・保存するには多額の費用がかかるため、多くの組織では多数のシステムに非常に短いRTOを維持できません。
ディザスタリカバリと事業継続を計画する
高性能なディザスタリカバリまたは事業継続計画の導入を検討します。より高度な復旧プラットフォームに投資できる大企業にとって、これはRTOの期待値を達成するうえで大きな違いを生みます。こうしたソリューションの選定・導入には時間と関係者の承認が必要ですが、特にミッションクリティカルなシステムを多数抱える組織にとって価値あるリソースです。
目標復旧時点（RPO）の仕組み
組織の目標復旧時点は、損失許容度、つまり重大な損害が発生するまでに失ってもよいデータ量を指します。RPOは、損失が発生した時点と直近のバックアップとの間の時間を測定する指標です。
企業がすべてまたは大半のデータを24時間間隔で定期的にバックアップしている場合、最悪のケースでは24時間分のデータが失われます。アプリケーションによっては許容できますが、許容できない場合もあります。
RPOの算出
RPOは、段階的なプロセスで算出できます。以下のガイドラインに従い、重要なすべてのシステムについて時間範囲を選択し、重大な損害を被らずに企業が失ってもよいデータ量を判断します。
- 例えばクラウドストレージプラットフォーム、CRMソリューション、eコマースアプリケーションなど、各エンタープライズアプリケーションでデータをどれほど速く利用可能にする必要があるかをテストします。
- 主要なエンタープライズアプリケーションを、バックアップ復元要件に基づいて分類します。例えば、データは数分以内に復元する必要があるのか、それとも1日待てるのかを判断します。
- バックアップに関する企業の財務状況を算出します。フェイルオーバーやレプリケーションサービスを維持できるのは何個のアプリケーションか。物理ハードディスクなど、一部のバックアップをオフラインで保管する必要があるか。
- 即時復旧の優先度が最も高いアプリケーションを選びます。主要クラウドプラットフォームを支えるサーバーで継続的レプリケーションを実行していれば、短時間で復旧できます。一方、過去の営業連絡先を保存したデータベースをハードディスクから復元するには数時間かかる場合があります。ほとんどの企業はすべてのソフトウェアを迅速にバックアップする余裕がないため、慎重に優先順位を付けます。
RPOの目標を設定する
アプリケーションの優先度によって異なりますが、個々のRPOは通常、ほぼゼロ（秒単位）から24時間の範囲です。8時間を超えるRPOを設定する企業は、既存のバックアップソリューションで達成できる可能性があります。ただし、その実行による本番システムへの影響が最小限であることが条件です。
4時間のRPOには、スケジュールに基づくスナップショットレプリケーションが必要です。ほぼゼロのRPOには継続的レプリケーションが必要です。RPOとRTOがともにほぼゼロの場合、継続的レプリケーションとフェイルオーバーサービスを組み合わせることで、アプリケーションとデータの可用性をほぼ100％にできます。
アプリケーション関連のRPO目標を設定する
影響を受けるアプリケーションに保存されるデータの種類と緊急性に基づいてRPOの目標を設定します。例えば、あるアプリケーションのRPOが4時間なら、データが失われる前にバックアップできる最大時間は4時間です。
RPOが4時間だからといって、必ず4時間分のデータを失うとは限りません。深夜0時に障害が発生し、午前1時15分までに復旧したワープロアプリケーションなら、何も失わない可能性があります。しかし、午前10時に利用量の多いアプリケーションが停止し、午後2時に復旧した場合、企業は価値が高く、場合によっては置き換えのきかない情報を数時間分失う可能性があります。このようなケースでは、アプリケーション固有のRPOを達成するため、より頻繁にバックアップを実行します。
RPO達成のベストプラクティス
RTOの理想値と同様に、まずは現在のリソースで企業が現実的に達成できるRPOを理解します。目標を設定する前に、さまざまなフェイルオーバー・レプリケーションサービス、ハードディスク、フラッシュアレイについてバックアップ速度をテストします。過去の復旧にかかった時間を確認するため、履歴データを調べます。過去の傾向と大きく異なるRPOを達成しようとすると、失望や不満につながるだけでなく、企業がリソースを拡大する必要性を示すことがあります。
スタッフのトレーニングも不可欠です。バックアッププロセスに関わるすべての担当者は、インシデントや停止が発生した際に迅速かつ速やかに対応できなければなりません。そうすることで、システム停止時に何をすべきかを理解し、緊急時にも自信を持って行動できます。
テクノロジーのアップグレードも必要になる場合があります。レプリケーションとフェイルオーバーサービスが信頼性の高い最新のものであることを確認します。古く信頼性の低いサーバーでホスティングされているサービスは、十分な速度で動作しない可能性があります。同様に、企業ネットワークがデータのバックアップ速度を支えられるよう、ネットワークパフォーマンスを最適化します。トラフィックが多いと、組織が所定のバックアップ時間を達成できなくなる可能性があります。
RPOとRTOの共通点と違い
RPOとRTOは、ディザスタリカバリまたは事業継続計画において重要な検討事項です。事業影響分析は、RPOとRTOの両方を算出する初期段階で利用できます。
RTOはダウンタイムの長さに関係します。RPOはデータ損失とバックアップ頻度に関連します。ダウンタイムの原因には企業が制御できないものもありますが、企業のリーダーはバックアップの頻度を決定し、潜在的な被害を抑えられます。
RTOは、影響を受けた組織が業務を再開するまでにかかる時間を判断する、将来を見据えた指標です。一方、RPOでは最後にデータをバックアップした時点と、問題によって企業が失う情報量を確認するため、過去を振り返ります。
RPOとRTOを使う場面
企業が失うことを許容できない、事業運営に不可欠なデータを扱う場合は、目標復旧時点を使用します。また、規制当局への対応として特定のデータ要件を満たす必要がある場合にも、RPOが適しています。
クラウドと物理的な場所など、複数の場所に情報を保存する際に目標復旧時点を設定する動きも広がっています。このような構成はより複雑で、追加の予防策が必要です。
ランサムウェア攻撃の増加も、企業のリーダーがRPOをより重視するきっかけになっています。RPOを重視することで、インシデントの影響を抑え、身代金の支払いを迫られる可能性を減らせます。頻繁にバックアップを実行し、堅牢な復旧計画を持つ企業は、深刻な財務上の影響や業務の中断を受ける可能性が大幅に低くなります。
目標復旧時間の最適なユースケースは、短時間の停止でも壊滅的な結果につながるケースです。緊急 dispatchシステムや、重要な産業システム向けの監視ツールが好例です。
停止に伴う顧客関連の影響を検討します。例えば2022年、TicketmasterはファンがTaylor Swiftのチケットを購入しようとする中で停止しました。このインシデントはニュース記事やソーシャルメディアで広く報じられ、批判も集めたため、他社にとって運営上の悪例となりました。
目標復旧時間のユースケース
以下の例では、企業が壊滅的な結果を回避するうえでRTOが役立つさまざまな用途を紹介します。
重要なメールの復旧
ある企業の弁護士が、時間的制約のあるメールを誤って削除し、さらにごみ箱の内容も空にしてしまいました。しかしIT部門は、この多忙な企業にとって重要なアプリケーションであるMicrosoft Exchangeの差分レベルの変更を継続的にバックアップしています。バックアップアプリケーションはきめ細かなバックアップと復旧に対応しているため、1通のメールのために仮想マシン全体を復元するのではなく、5分のRTOで個別のメッセージを復旧できます。
eコマースサイトの可用性を確保する
ある店舗の自社ホスティング型eコマースサイトは、3つのデータベースを使用しています。商品カタログを保存するリレーショナルデータベース、過去の注文データを報告するドキュメントデータベース、そして決済処理業者のゲートウェイに接続するAPIデータベースです。
ドキュメントデータベースは他のデータベースからデータを再構築できるため、RTOとRPOは24時間以内です。企業がリレーショナルデータベースに商品を追加するのは週1回だけなので、RPOは重要ではありません。しかしRTOは重要です。データベースが停止すると、顧客取引が止まるためです。
企業はフェイルオーバーサービスに投資し、データベースが仮想サーバー上ですぐに起動するようにしました。週内に加えられたわずかな変更は、プロバイダーのディザスタリカバリプラットフォームにレプリケーションしています。APIデータベースには注文情報が保存されており、RPOとRTOの両方を秒単位にする必要があります。IT部門はデータをフェイルオーバーサイトへ継続的にレプリケーションし、APIデータベースが停止すると、そのサイトが直ちに処理を引き継ぎます。
目標復旧時点のユースケース
以下の例では、イベント発生後の事業継続を維持するためにRPOを使用するさまざまな用途を紹介します。
CRMプラットフォームの復元
ある企業のフロリダ州の本社でホスティングしているCRMソフトウェアが、激しい暴風雨の発生時に停止しました。サーバールームは損傷しましたが、CRMデータはすべてミズーリ州のデータセンターにバックアップされていました。CRMプラットフォームは重要度が高いため、チームはレプリケーションとフェイルオーバーサービスを優先し、暴風雨が襲来する数分前にデータセンターのバックアップをレプリケーションしていました。
復元を担当するチームメンバーの多くは州外にいて、フロリダで直接作業していませんでしたが、ディザスタリカバリ計画のエスカレーションプロセスに直ちに従い、15分のRPOを達成できました。
時間指定のハードドライブバックアップを設定する
バックアップは、自動的に実行されるか、最小限の管理で済む場合に、関係者全員にとって最も便利です。AppleのMacコンピューターには、バックアップを処理するTime Machineアプリケーションが搭載されています。Time Machineを使うMacに外付けドライブを接続してアプリケーションを有効にすると、以下の自動バックアップを実行します：
- 過去1日分を1時間ごとにバックアップ
- 過去1か月分を毎日バックアップ
- 1か月を超える期間については毎週バックアップ
この場合、データを復元する必要に気付いた時点で、最新のバックアップ復元ポイントが使用されます。ほとんどの企業は、Time Machineが提供するものよりも高度なテクノロジーを使用しています。しかし、このアプリケーションの仕組みは、RPOを設定する前に、データに関する重要な決定を下す必要がある理由を明確に示しています。
要点：企業のバックアップと復旧の目標を優先する
RTOとRPOの管理は、企業が戦略的にデータバックアップの目標を達成するうえで重要です。これらの指標により、組織はバックアップと復旧の戦略を策定する際に検討すべき具体的な基準を得られます。さらに、これらの重要業績評価指標を決定することで、膨大なタスクをより管理しやすくできます。
すべての組織にとっての課題は、アプリケーションに優先順位を付け、どのアプリケーションにより多くの財務的投資が必要かを判断することです。企業は、即時復旧ソリューションにどれだけの費用をかけられるでしょうか。各システムのRTOとRPOを把握することで、判断に役立ちます。
企業のリーダーは、一方だけを測定してもう一方を測定しないのではなく、RTOとRPOを同じように不可欠なものとして扱うべきです。どちらの指標も、事業にとって最も重要なアプリケーションとデータ、そして業務を成功させるためにそれらを稼働させ続けるうえで必要なことを明らかにします。
企業データ管理の原則をさらに詳しく知るには、11 Data Backup Best Practicesをご覧ください。