RTO (目標復旧時間)

RTO (目標復旧時間) とは何か?

RTO (目標復旧時間) とは、障害またはデータ損失インシデントが原因でアクセスできなくなったアプリケーション、サービス、データ、またはその他のデジタル資産の機能を組織が回復するまでに許容できる最長時間と定義されています。RTOは、可能な限りゼロに近づけるのが理想です。RTO (目標復旧時間)はRPO (目標復旧時点) と異なり、RTOはシステムが通常通りの状態に戻るまでの時間を対象にしているという点です。これに対しRPOは、失われる可能性があるデータ量を対象としています。つまりRPOとは、アプリケーションがビジネスに損害を与える前に許容できる最大のデータ損失量のことです。

なぜRTOが重要なのか?

デジタルトランスフォーメーションの時代において、企業、そして顧客やパートナーも期待しているのは、常時オンのITサービスと24時間体制のIT運用です。セキュリティやコンプライアンスに対する高まる要件も確実に満たす必要があります。しかし、ランサムウェア攻撃のような絶えず巧妙化するサイバー脅威は、企業が最小限の停止時間でミッションクリティカルなアプリケーションを保護し、予測どおりに復旧する方法をますます複雑化しています。

企業はあらゆる災害に備え、ビジネスに備える必要があります。これには、デジタル資産が利用不能となり、ビジネスに損害を出すまでにかかる最長の時間 (RTO)を把握することも含まれます。ただし、RTOの長さに関しては、すべてのアプリケーションで同じように作成されるわけではありません。ITチームとアプリケーションチームは協力して、ビジネスにとって最も重要な資産のRTOを優先しなければなりません。また、個別のアプリケーション、サービス、その他資産のRTOをすべて把握しておくことは、予期しない停止に直面してもビジネスが継続して完全に機能する上で不可欠です。

RPOとRTOの違いとは?

RPOとは、データを失ってもビジネスに損害を発生させないままアプリケーションが耐えられる、データ損失の最大許容量のことです。RTOとは、運用に悪影響を生じさせないままアプリケーションを停止可能な時間のことです。

プロジェクトのRTOとは?

プロジェクトのRTOとは、プロジェクトにアクセスできない状態でビジネスに損害を発生させることのない、最長許容時間のことです。

RPOとRTOの例とは?

RTOは、企業がアプリケーションやデータなどのデジタル資産の機能を回復するまでにかかる最長の許容時間のことで、秒、分、時間、日単位で計測します。RTOは企業のデータ復旧計画で重要な役割を果たします。さらに、今日のような常時オンが当たり前のデジタル世界では、RTOは非常に短くなければなりません。例えばクレジットカード代理店の取引システムでは、2〜3秒など、RTOをできる限りゼロに近づける必要があります。これはつまり、システムがダウンした場合、IT部門はわずか2～3秒でシステムをオンラインに戻せるということです。

インシデント発生時に失われる可能性のあるデータ量を対象とするRPOは、アプリケーションがビジネスへ悪影響を及ぼさずに済む、データ損失の最大許容量のことです。また、この値は時間単位で測定されます。具体的には、最後のデータバックアップから障害が発生するまでの時間です。例えば、銀行はデータのバックアップをほぼリアルタイムで行い、常に最新のデータを利用可能な状態にしておく必要があります。例えば障害が発生したとき、直近のデータバックアップが10秒前に実行されていて、アプリケーションのRPOが15秒である場合は、RPOの条件を満たしていると言えます。

データの復旧におけるRPOとは?

RPOはデータの復旧において重要な要素です。これは次の大きな問いに答えるものです: インシデントでどの程度のデータが失われたかを考えて、システム (アプリケーション、サービス、その他のデジタル資産) を復旧するにはどれくらいの時間がかかるのか?

要するにRPOは、データの復旧オペレーションを計画する際に現実的な状況を提供するのです。チームはRPOを使用し、バックアップの間隔が障害発生時に失う可能性のあるデータ量と等しいものと仮定して、バックアップの頻度に関するスケジュールを立てます。例えば金融サービスや医療の企業にとって、データの損失は致命的です。そのためこうした企業ではRPOをミリ秒単位で測定しますが、数時間または数日分のデータを失っても業務に悪影響を受けない企業もあります。

RTOとRPOの測定方法とは?

RTOとRPOはどちらも、秒 (もしくは1秒未満)、分、時間、もしくは日数で計算されます。しかし、この2つの測定対象は異なります。RTOとは、システムが停止してもビジネスに悪影響が生じない最長の時間のことです。RPOは、損失する可能性があるデータの量を表しています。

RTOの計算方法とは?

RTOは、ビジネスで許容できる停止時間の上限を計算することによって算出されます。次の質問に答えることで、この数値を算出することができます:

• このシステムのユーザー (内部および外部の両方) に対して、どのようなSLA (サービスレベルアグリーメント) がありますか?
• これは顧客向けシステムですか? このシステムが利用できない場合、顧客体験、ロイヤルティ、解約にどのような影響がありますか?
• このシステムが利用できない場合、どれほどの収益が失われますか?
• このシステムがオフラインになった場合、他のシステムも影響を受けますか? それらのシステムはどのくらい重要ですか? それらのSLAとRTOはどのようなものですか?

なぜRPOとRTOが重要なのか?

RPOとRTOは、今日のような常時オンが当たり前のビジネス環境に求められる重要な指標です。その数ある重大なメリットには、以下のものが挙げられます:

• データ復旧と災害復旧 (DR) の計画がより効果的に: 予期しない障害が発生した場合、チームはビジネスで許容できるデータ損失量または停止期間を把握する必要があります。RTOとRPOを計算することで、企業は現実的かつビジネスを保護するデータ戦略とDR戦略を策定するための、実用的なガイドラインが手に入れることができます。
• 最もビジネスクリティカルなアプリケーションを特定して保護する: ビジネスはアプリケーションの上で動いています。アプリケーションの中には、それらなしでは機能しないほど重要なものもあります。そうしたアプリケーションを把握することは、想定外の障害が発生した際に備えて優先順位付けを行ったり、ビジネス全体の継続性を支えるRTOやRPOの値を指定するために非常に重要です。
• ITとアプリケーションの所有者がSLAの定義を行えるようにする: IT組織がユーザー (内部および外部) へ一定レベルのシステム稼働時間や品質を約束する前に、それらが現実的であることを確認するためRTOやRPOを計算する必要があります。IT部門がRTOまたはRPOを下げることができれば、SLAの改善を約束し、顧客と従業員の満足度を高める機会を得ることができます。

RPOをRTOよりも低くするべきか?

いいえ、RPOをRTOよりも低くする必要はありません。2つの数値に直接的な相関関係はありません。どちらもデータと災害復旧オペレーションの確立と管理を行う上で重要ですが、一方の値を他方より低く (あるいは高く) する必要はありません。例えば、RTOが5時間でRPOが30秒、もしくはRTOが5分でRPOが24時間、といった設定も可能です。

バックアップにおけるRPOとRTOとは?

RTOとRPOは、企業がデータのバックアップ頻度を決定する際に現実的な値を提供するものです。実際に、バックアップの間隔は、特定のアプリケーションの停止によって企業が失う可能性のあるデータ量に等しくなります。IT部門はビジネスオーナーと協力しながら、アプリケーションやサービスなどの各デジタル資産に対するRTOとRPOを計算し、これらの値に収まるようなバックアップのスケジュールを立てる必要があります。例えば、データの損失が致命的となる金融サービスや医療業界では通常、RPOをミリ秒単位で測定します。この場合、ほぼ継続的なバックアップが必要になります。

CohesityとRTO (目標復旧時間)

今日のビジネスは24時間365日体制であるため、企業はRTO (目標復旧時間) とRPO (目標復旧時点) の両方を可能な限りゼロに近づけようとしています。数時間や数日ではなく、数分または数秒にするのが理想です。

しかし、従来の災害復旧やデータ保護製品へ多額の投資を行っているのにもかかわらず、企業では未だに停止時間が発生し、多くの場合は売上や収益の損失、違反に対する罰金、生産性の低下といった形で多大な損失に繋がっています。

このようなビジネスへの悪影響は、データ保護計画でその目的を達成できない場合、顧客や従業員からの信頼が失われることでさらに悪化します。しかし、RTOとRPOを下げようとして、非常に多くの企業が高価で複雑な1回限りの製品を導入していますが、望み通りの常時オンの企業を実現するには継続的なメンテナンスが必要です。

Cohesityはエンドツーエンドのデータ保護インフラ (ターゲットストレージ、バックアップ、レプリケーション、災害復旧、クラウド階層化など) を統合することで、従来のデータ保護ソリューションの複雑さを解消する業界唯一の統合プラットフォームを提供します。