RTO (リカバリ時間目標) とは、停止または損失が発生した後でシステムまたはデータを復元するまでの時間を指します。RTO 目標は、ディザスタリカバリ計画の短期目標と長期目標を設定するために使用されます。
すべてのエグゼクティブが最低限望んでいるのは、業務が円滑に進むことです。物事が円滑に進んでいれば、大きな問題は発生しないからです。しかし、円滑に進むことはほとんどありません。
企業では、業務を中断する問題が頻繁に発生し、それがコストのかかるダウンタイムにつながっています。調査によると、過去数年間でダウンタイムは 82% の企業に影響を及ぼしています。ダウンタイムの平均コストが時間あたり 300,000 ドルであることを考えると、ビジネスが停止する可能性があります。
今日のデジタル社会では、あらゆる規模の企業が最悪の事態に備えなければなりません。計画がない場合、ランサムウェア攻撃、データ侵害、自然災害により、企業が回復不可能な損害を被る可能性があります。
効果的なバックアップとディザスタリカバリ計画がなければ、インシデント発生後に復旧して稼働開始するまで数日、あるいは数週間かかる可能性があります。つまり、収益と生産性が失われ、回復不可能になる可能性があります。
企業を中断から守るための方法があります。それがリカバリ時間目標 (RTO) です。RTO により、企業は停止または攻撃発生後にシステムを復旧するための現実的な目標を設定して、ダウンタイムを最小限に抑えることができます。RTO をバックアップとディザスタリカバリ計画に含めれば、何が起こっても対応できるという安心感が得られます。
前述のとおり、停止やダウンタイムはビジネスを大幅に中断する可能性があります。さらに、このような問題が発生した場合、IT システムとインフラが最適な状態に復旧するまで、ある程度の時間がかかります。場合によっては、IT システムとインフラで障害が発生し、再び機能させるために介入が必要になることがあります。
これを理解することが、このようなインシデントの影響を抑えるための鍵となります。業務が中断する前にシステムを再稼働させるには、どのぐらいの時間があるかを知っておく必要があります。ここで役に立つのがリカバリ時間目標です。
RTO は、ダウンタイム期間後に業務の中断を最小限に抑えてシステムまたはアプリケーションを復元するまでの時間を計算するのに役立つ重要な指標です。基本的には、企業が受容できるダウンタイム時間です。
システムごとに役割は異なり、さまざまな形で業務に影響を及ぼすため、システムごとに固有の RTO が必要です。各システムでこれを定義すれば、迅速なシステム復元を実現するためのリカバリ戦略を策定することができます。
つまり、RTO が 1 時間の場合、システム復旧の担当者はその期間内に復旧する必要があります。
設定するリカバリ時間目標は、ビジネスニーズに沿ったものにする必要があります。たとえば、オンライン支払いシステムのリカバリ時間目標は、コンテンツ管理 Web サイトよりも短くしなければなりません。このように、設定するリカバリ戦略は、直面するリスクに合わせます。
一方、手動請求を使用できる企業では 1 ～ 2 日、場合によってはそれより長い RTO を設定できます。
設定された RTO 内でシステムを稼働することが理想的ですが、常に達成できるとは限りません。
これには特に、サービスプロバイダのシステムが停止した場合や自然災害の発生後など、極限の状況が考えられます。
このような場合、ダウンタイムの損害額が膨大になるのを待つのではなく、重要な IT 業務をアウトソーシングすることを検討します。これにより、RTO を抑制し、ダウンタイムを最小限に抑え、最終的に潜在的な損失から企業を守ることができます。
リカバリポイント目標 (RPO) は、RTO と同様の指標です。RPO は、インシデントまたは中断発生後に企業が許容できる最大のデータ損失量を示す指標です。
RTO はシステムリカバリ時間に重点を置き、RPO はデータ保護とリカバリ目標に重点を置きます。RPO は、業務に影響を及ぼす前に失っても差し支えないデータ量を示す指標です。
RTO と RPO は、バックアップとディザスタリカバリ計画で使用される 2 つの指標です。測定する対象は異なりますが、どちらの指標も、同じレベルの注意を払い、企業のニーズを考慮して設定する必要があります。
どちらも、インシデントまたは中断の発生後に業務を復旧するまでの時間を示す指標として使用されます。これらの指標を設定するときは、企業のニーズ、リスクプロファイル、予算、その他の要素を考慮に入れます。
RTO では、システムを再稼働するまでの所要時間に重点を置いていますが、RPO は、業務に影響が及ぶ前に許容できるデータ損失量を示す指標です。
今日、企業の主な差別化要因は、プロセスを動かすテクノロジです。デジタル化によって間違いなく効率が高まり、カスタマーエクスペリエンスが向上し、業務が変革されました。
ただし、企業はテクノロジに過度に依存するようになっていますが、これはシステムが停止して初めて問題になります。これは、ダウンタイムの損害額が大きいためです。したがって、適切な RTO の策定が不可欠です。
ダウンタイムが発生すると、直接的な収益を失うだけでなく、問題を解決するための人時の追加と IT システムを置き換えるための費用も発生します。合計コストは、IT システムの置き換えが必要になる場合、100 万ドルを超える可能性があります。このため、ダウンタイムとリカバリに備えることが不可欠です。
そのために RTO が役に立ちます。これにより、企業はリカバリプロセスを常に制御し、停止によって発生する遅延を少なくすることができます。また、予期しないダウンタイムが発生した場合の計画も提供されるため、損失を最小限に抑えながら、迅速に業務を再稼働できます。
RTO の計算は複雑になる場合があり、ダウンタイムの損害額、ディザスタリカバリとバックアップソリューションへの投資額、システムをオンライン復旧させるための担当者コスト、規制要件、その他の要素など、複数のコンポーネントが関係します。
RTO を決定するには、これらのすべてのコンポーネントを考慮し、企業のリスクプロファイルと予算に基づいてタイムラインを確立することが重要です。さらに、以下を考慮に入れます。
これらを念頭に置いて、RTO の計算へと進むことができます。実行する手順は次のとおりです。
RTO を達成するかどうかには、さまざまな要因が影響します。したがって、適切なバックアップとディザスタリカバリ計画を策定することが重要です。
RTO の達成には、バックアップソリューションとディザスタリカバリ計画が不可欠です。これらのソリューションにより、企業はダウンタイム、データ損失、またはその他の中断から迅速に回復できます。
バックアップ計画には、プロバイダとのサービスレベル契約 (SLA) で保証されている RTO を含めます。また、以下の機能も提供されます。
企業のリカバリ時間目標の達成は、バックアップおよびディザスタリカバリソリューションを通じて可能になります。これらのソリューションは、さまざまな機能を備えています。このようなソリューションを最大限に活用して、RTO をほぼゼロにするには、これらの重要な機能に注意を払うと役に立ちます。
ほぼゼロという意欲的な RTO 目標を達成するには、結果を即時に提供するリカバリオプションが必要です。このため、ディザスタリカバリ戦略の一環として即時の復元機能が必要になります。それにより、保存済みのマシンをバックアップストレージから直接起動し、クラウドストレージ上などのすぐに使用できる状況で仮想的に運用することができます。
これは、予期しないダウンタイムの発生中に業務を遅らせないようにする必要がある企業にとって不可欠です。また、医療業界など、特定のデータを迅速に復元する必要がある企業にもメリットをもたらします。
RTO を成功させるには、柔軟かつ調整可能な RPO ポリシーが不可欠です。企業の現在のニーズに従って RPO を調整することができます。
たとえば、RTO 要件が変更された場合、その変更に従って RPO ポリシーを調整できます。また、RPO は通常、特定のプロセスまたはアプリケーションに対して設定されるため、それぞれの RPO の調整はさらに簡単で効率的です。
RTO 目標を策定するには、継続的なデータ保護 (CDP) が必要です。これにより、変更頻度に関係なく、すべてのデータがバックアップされ、保護されます。また、CDP により、失われたデータや破損したデータを迅速に復元できます。
CDP は重要なワークロードに使用できますが、高いリソース使用率から、パフォーマンスと安定性の問題が発生する場合があります。このため、CDP は主にファイルレベルのバックアップで実装されます。
ほぼ連続的なデータ保護 (NCDP) とは、ほぼリアルタイムのバックアップと復元を保証する RPO ポリシーです。また、わずか数分の限定的な RTO により、パフォーマンスへの影響を最小限に抑えます。つまり、データが失われてもすぐに復元できます。
NCDP ソリューションは、ほぼゼロの RTO 目標を維持しようとする企業に最適です。ただし、CDP と同様、NCDP でもリソースの使用が必要なことから、パフォーマンスと安定性に悪影響が及ぶ可能性があります。
きめ細かなリカバリ機能により、データセット全体を復元する代わりに、バックアップから個々のファイルをリカバリできます。データセット全体の復元を待つことなく、個々のファイルを迅速に復元できるため、これは RTO シナリオで非常に役に立ちます。
きめ細かなリカバリは、特定のプロセスの特定の結果に左右される RTO ポリシーでも役に立ちます。これらのプロセスの影響を受けたコンポーネントを復元するだけで済み、その他は復元する必要がなくなります。
RTO 目標の達成に向けた準備にあたって、データのオフサイトコピーは不可欠です。これは、セカンダリデータリポジトリにより、プライマリストレージ場所での災害シナリオまたは停止から迅速にリカバリできるためです。
フェールオーバーによるライブレプリケーション機能は、検討すべきもう 1 つの RTO 関連機能です。これにより、データの可用性をリアルタイムで維持でき、失われたデータを復元する際に手動による介入が不要になります。
また、ある場所で障害または中断が発生した場合、プライマリサイトとセカンダリサイトを迅速に切り替えることができます。フェールオーバーによるライブレプリケーションにより、企業は中断とダウンタイムを最小限に抑え、RTO 目標を維持することができます。
停止発生中でも業務を継続しなければならない企業にとって、RTO 戦略は不可欠です。RTO 戦略の計画に関するヒントをいくつかご紹介します。
ディザスタリカバリ計画の作成は難しく、そのためのベストプラクティスを知っていても、予算に関する懸念のほうが優先される傾向にあります。このような計画を作成する際は、コストを第一に考慮するのではなく、業界標準のベストプラクティスの次に考える必要があります。
さらに重要なのは、機能と期待を同期させることです。
RTO 戦略には、包括的なディザスタリカバリ計画を含める必要があります。この計画には、停止からリカバリするために担当者が実行する手順を記述し、さまざまなチームの役割と責任を列挙します。
ディザスタリカバリ計画には、RPO、RTO、データバックアップ、レプリケーションスケジュール、ディザスタリカバリ計画のテストプロセスも含める必要があります。
定期的なディザスタリカバリ計画のテストは、企業が業務をタイムリーかつ円滑にリカバリするために不可欠なものです。このプロセスは多くの IT 部門にとっては面倒なものですが、アプリケーションレベルまでリカバリをテストしなければなりません。テストしないと、問題発生の原因になります。ディザスタへの備えを成功させるには、潜在的な問題を発生前に完全に認識しておくことが必要です。
ディザスタリカバリテストは軽視せず、実稼働レベルまでの包括的なエンドツーエンドテスト手順と考えなければなりません。相互依存の関係がある多層クライアントサーバーや Web ベースの構造といった複雑さを考えると、ディザスタリカバリの主な焦点は、サーバーからアプリケーションへシフトする必要があります。
適切な準備を怠ると、問題発生の可能性が高まります。したがって、企業が潜在的な災害に耐えられるようにするには、これらのテストをアプリケーションレベルまで実行して成功させる必要があります。
新たな脅威が登場し、さらに既存の脅威が進化し続けていることを考えると、ディザスタリカバリを同じままにしておくことはできません。定期的にテストし、現在の傾向や脅威に対応するように更新する必要があります。
リカバリ時間目標の定義は、RTO 計画を成功させるための重要な要素です。責任を特定の部門やチームに割り当て、それぞれに具体的な役割を理解させることが不可欠です。
災害が発生した場合に迅速に行動できるよう、全員が RTO 計画の変更や更新を認識しておくことも重要です。特に、意思決定のとき、および停止やデータ損失の発生中に特定のタスクの担当者を決定するときには特に重要です。
もう 1 つの重要な手順は、計画の定期的な更新です。これには、新しい RPO、RTO、データバックアップ情報による更新、関連性が失われた既存プロセスまたは手順の変更が含まれます。さらに、アプリケーションやシステムを最近アップグレードした場合は、これらの変更も RTO 計画に反映させる必要があります。
RTO 計画を作成する際は、現実的な目標を設けることが重要です。これらの目標には、特定の時間内での重要な業務の復元、特定の期間内でのシステム運用の完全復旧など、短期目標と長期目標の両方を含める必要があります。
RTO 目標を現実的で達成可能なものにするには、テクノロジの現在の状態、利用可能なリソース、停止やデータ損失の発生中に遭遇する可能性がある潜在的な脅威またはリスクを考慮することが重要です。リカバリ時間目標を設定したら、定期的にテストして、達成可能であることを確認します。
RTO に関しては、信頼性の高い最新のバックアップの確保が不可欠です。セキュリティを高めるために、データは定期的に、できれば複数のプラットフォームにバックアップする必要があります。また、データをバックアップするときは、データの最新バージョンが保存されるようにし、データの損失を抑えます。
バックアップは、RTO または RPO 違反が発生した場合の企業の迅速な復旧にも役立ちます。適切なバックアップが確保されていれば、ダウンタイムを中断の最小限に抑え、容易にデータとシステムを復元できます。
信頼性の高いリカバリ時間目標ソリューションをお探しなら、ベリタスをご検討ください。ベリタスのソリューションなら、RTO または RPO 違反が発生しても、迅速かつ効果的に業務を復旧できます。自動化されたツール、分析、エンドツーエンドの RTO 機能が幅広く用意されており、脅威に対してプロアクティブに計画して対応できます。
ベリタスとの連携には、次のようなメリットがあります。
RTO 計画は、RTO または RPO 違反が発生した場合のダウンタイムと中断を短縮しようとしている企業にとって不可欠なものです。現実的で達成可能な目標を設け、信頼性の高いバックアップとエンドツーエンドのリカバリ時間目標機能を確保することが重要です。
ベリタスのリカバリ時間目標ソリューションにより、企業は RTO 脅威に備え、侵害が発生した場合でも中断を最小限に抑えることができます。ベリタスのソリューションなら、RTO と RPO をプロアクティブに計画し、分析を使用して傾向を追跡し、潜在的な脅威を特定することができます。
今すぐベリタスに問い合わせて、ソリューションの詳細と、包括的な戦略の準備をベリタスがどのように支援できるかをご確認ください。
ベリタスのお客様は Fortune 100 企業の 95% を占めています。また、NetBackup™ は大量のデータの保護を検討している大企業にとって第一の選択肢です。
完全なデータ保護を仮想、物理、クラウド、およびレガシーの各ワークロードに対してベリタスの大企業向けデータ保護サービスがどのように維持しているかをご確認ください。
RTO (リカバリ時間目標) とは、停止または損失が発生した後でシステムまたはデータを復元するまでの時間を指します。RTO 目標は、ディザスタリカバリ計画の短期目標と長期目標を設定するために使用されます。
RTO 目標は定期的にテストし、達成可能であることを確認する必要があります。これには、RTO シナリオのシミュレーション、RTO 違反の場合にシステムまたはデータセットを復元するのにどれだけ時間がかかるかのテストが含まれます。
ベリタスの RTO ソリューションは、自動化された RTO および RPO 計画、エンドツーエンドの RTO 機能、分析とレポート、高度な分析を提供します。これにより、RTO の脅威に備え、RTO 違反が発生した場合でも中断を最小限に抑えることができます。