RPO (目標復旧時点)

サポートヒーローバナー

RPO (目標復旧時点) とは?

RPO (目標復旧時点) とは、ビジネスに損害を発生させる前に組織が耐えられるデータ損失の最大許容量のことです。RPOは、ダウンタイム発生から最後のバックアップまでの時間で計算されます。

RPOは、ダウンタイム発生による全体的な損失を最小限に抑えるという災害復旧 (DR)目標にとって重要なもので、これは必然的にビジネスの側面にまで波及する可能性があります。すべてのアプリケーションやシステムが同じように作られているわけではありません。そのため、最も貴重なデータを有する最も重要なアプリケーションを優先して迅速にオンラインに戻すことが重要です。この優先順位付けは、データ損失に対する耐性を最大化するための事業継続計画の重要な部分です。

なぜRPO (目標復旧時点) が重要なのか?

デジタル化が進む今日の世界では、ミッションクリティカルなアプリケーションで実行されるデータが、あらゆる種類や規模の組織を動かしています。また、従業員、顧客、パートナーを含む企業は、常時オンのITサービスと24時間体制の運用を期待しています。しかし、ランサムウェアのような絶え間なく進化するサイバー脅威により、ダウンタイムを最小限に抑えながら重要なデータを保護し、予測可能な形で復旧させる取り組みを強化する必要に企業は迫られています。

あらゆる種類の災害による計画外のダウンタイムに直面しても、迅速に復旧し、事業継続性を確保できるよう準備するためには、チームは、RPOによって定義された損失しても差し支えないデータの最大量を把握しておく必要があります。しかし、RPOに関しては、すべてのデータがビジネスにとって同等に価値があるわけではありません。ITチーム、アプリケーションチーム、機能別部門が協力して、ビジネスにとって最も重要なデータ資産のRPOを優先しなければなりません。

RPOが重要なのは、組織がシステムやデータに対する障害のリスクを評価するのに役立つからです。また、組織が必要とするレベルの粒度でデータを復旧するために必要な、バックアップ頻度の決定にも役立ちます。

RTOとRPOの違いは?

RPOとは、データを失っても組織に損害を発生させないままビジネスシステムが耐えられる、破壊的な出来事から最後のバックアップまでに発生するデータ損失の最大許容量のことです。

RPOはRTO (目標復旧時間) とは異なり、障害が原因でアクセスできなくなったアプリケーション、サービス、データ、またはその他のデジタル資産の機能を組織が回復するまでに許容できる最長時間のことを指します。

組織は高い満足度を維持するため、RPOとRTOの両方を可能な限り低くしたいと考えます。

レジリエンスにおけるRTOとRPOとは?

レジリエンスとは、プロセス、運用、またはIT環境に障害が発生しても、組織がビジネスを支障なく継続できる能力のことです。

ITのレジリエンスは、RTO (目標復旧時間) とRPO (目標復旧時点) の指標によって評価することができます。RTOは、障害発生後にアプリケーションがオフラインでいられる最長時間のことですが、RPOは、ビジネスに悪影響が出るまでにアプリケーションが耐えられる、データ損失の最大量のことを指します。

RPOを改善するには?

組織がRPOを改善する方法は以下のようにいくつかあります:

  • バックアップ頻度を上げる: バックアップ頻度を上げることでRPOを短縮することができます。全データを対象とするとこの方法は現実的でないかもしれませんが、ビジネスクリティカルなデータについては、より頻繁の高いバックアップスケジュールを作成すべきです。これにより障害発生時に失われるデータが少なくなるため、RPOを即座に改善することができます。
  • 高度なバックアップ技術を使用する継続的データ保護 (CDP) やレプリケーションといった最新のバックアップ技術は、RPOの大幅な短縮に役立ちます。こうした技術を利用するとデータをリアルタイム、またはほぼリアルタイムでバックアップできるため、常に最新に近いデータをリカバリに使用することができます。
  • データのレプリケーション — 機能停止が発生した場合に組織が即座にフェイルオーバーできるライブデータのセカンダリコピーを作成することで、チームはRPOを劇的に向上させることができます。これにより、サーバーから別のサーバーへと切り替えを行う際に発生するデータ損失を限定的にすることができます。繰り返しになりますが、RPOはレプリケーションの頻度によって決まります。つまり、レプリケーション頻度が高ければ高いほど、RPOが向上するということです。
  • 重要データの優先順位を付ける: 組織は重要なデータやアプリケーションの優先順位を付けることで、バックアップ頻度を上げて該当システムのRPOを最小化することができます。
  • 定期的に災害復旧テストを実施する: 定期的な災害復旧テストは、災害復旧計画のギャップを特定し、RPOを改善するのに役立ちます。重要なシステムやデータの復旧をテストすることで、改善すべき領域を特定し、RPOを削減するための変更を加えることができます。

RPOの計算方法とは?

RPOは時間単位で計算します: 例えば、秒 (またはミリ秒)、分、時間といった単位です。重要でないデータや変化の遅いデータの場合は、RPOが数日になることもあります。ただ、この測定は正確に言えば時間を指しているのではありません。RPOとは、ある期間中、アプリケーションがビジネスに損害を与えるまでに失われる可能性のある、最大のデータ量のことです。

例えば、30分を目標としたRPOでは、30分ごとにデータを保存する必要があります。チームは、各アプリケーションで使用されるデータがビジネスにとってどれほど重要であるかによって、アプリケーションごとに個別のRPOを設定することができます。

RPOは、ビジネスが許容できるデータ損失の上限を計算することによって算出されます。次の質問に答えることで、この数値を算出することができます:

  • ファイルの更新頻度はどのくらいですか? 1時間ごとに更新されるようであれば、60分ごとにバックアップを実行すれば、事実上データが更新されるのとほぼ同時にバックアップをとることになるので、RPOはほぼゼロになります。
  • 事業継続計画目標はどんなものですか? RPOは事業継続計画の目的を支えるものでなければなりません。事業継続計画は、災害やその他想定外の障害が発生した場合に組織をどのように運営し続けるかを決定するものです。チームは事業を継続するために必要かどうかに応じて、アプリケーションごとに個別のRPOを設定する必要があります。例えば、投資銀行の金融トランザクションではゼロに近いRPOが必要となり、人事ファイルのような更新頻度がはるかに低いものより非常に短いRPOになります。
  • 組織が属する業界において、RPOの基準は何ですか? ビジネスにはそれぞれ独自のニーズがありますが、業界標準を確認することで、RPOの大まかなガイドラインを見出すことができます。先にも述べた通り、すべてのアプリケーションが同じRPOになるわけではありません。多くの場合、想定外の障害が発生した際に支障なくビジネスを運営するためにどの程度データが重要かということに応じて、チームはRPOの「階層」にアプリケーションを分類します。
  • 策定したRPOは、チームが必要とする形で機能していますか? 組織がアプリケーションのRPOを設定したら、IT部門はそれを継続的に監視しテストして、ビジネスのニーズを満たすのに十分な低さであることを確認する必要があります。そしてそれぞれの記録を文書化して最新の状態に保つことで、企業が耐えられると思われるデータ損失を把握することができます。そうすることで、チームは必要に応じて容易にRPOを見直し、バックアップスケジュールを調整することができます。

RPOの例とは?

ほとんどのビジネスでは、アプリケーションを評価して「階層」に分類します。この階層は、ビジネス要件、RTO (目標復旧時間)、予算に応じて組織が選択するものです。以下にRPOの階層の例を挙げます:

RPO階層1: データ損失ゼロ
これは、組織がいかなるデータ損失も許容できないという最高レベルのRPOです。通常は、金融システム、ヘルスケア、政府機関のサービスといった重要なアプリケーションで必要とされます。このレベルのRPOには継続的なデータレプリケーションが必要であり、通常は同期データレプリケーションが使用されます。

RPO階層2: 最小限のデータ損失
このRPO階層は最小限のデータ損失を許容するもので、通常は分単位で測定されます。重要ではあるが、階層1のアプリケーションほど機密性は高くないアプリケーションに適しています。このレベルのRPOには、通常、非同期データレプリケーションが使用されます。

RPO階層3: 限定的なデータ損失
このRPO階層は限定的なデータ損失を許容するもので、通常は時間単位で測定されます。重要度が低く、多少のデータ損失に耐えることができるアプリケーションに適しています。このレベルのRPOには通常、バックアップとリストアソリューションが使用されます。

RPO階層4: 広範囲のデータ損失
このRPO階層は広範囲のデータ損失を許容するもので、通常は日単位で測定されます。重要度が低く、相当量のデータ損失に耐えることができるアプリケーションに適しています。このレベルのRPOには通常、手動のプロセスとオフサイトへのバックアップが使用されます。

バックアップバックアップの代表的な種類とは?

バックアップと復旧ソリューションのほとんどが、数種類のバックアップオペレーションを提供しています。最も一般的なバックアップタイプは、フルバックアップ、増分バックアップ、差分バックアップです。

フルバックアップ: まさにその名の通りのバックアップです。フルバックアップでは、ひとつまたは多数のアプリケーションの全データに対し、完全なコピーを作成します。フルバックアップは最高のデータ保護を実現しますが、従来では多くの時間とストレージ容量を消費するため、継続的に行う企業はほとんどありませんでした。

増分バックアップ: 増分バックアップはフルバックアップから開始し、その後は前回のバックアップ以降に変更されたデータのみをバックアップします。バックアップ速度が速い上にストレージ容量が少なくて済むため、非常に人気です。

差分バックアップ: 差分バックアップはフルバックアップから開始し、その後のバックアップでは変更されたデータのみをコピーするという点では増分バックアップに似ています。増分バックアップと差分バックアップの違いは、増分バックアップには前回のバックアップ以降に変更されたデータのみが含まれるのに対し、差分バックアップには前回のフルバックアップ以降に変更されたすべてのデータが含まれるという点です。これにより変更されたあらゆるデータの保護が強化され、データのバックアップ漏れがなくなります。

バックアップとRPOの関係

RPOを計算することで、さまざまなアプリケーションのデータをどれくらいの頻度でバックアップすべきか、またどのようなバックアップを導入すべきかがわかります。例えば、金融サービスやヘルスケアといった規制の厳しい業界で業務を行うチームは、いかなるデータ損失も許されず、RPOはミリ秒単位で測定されます。この場合は、ほぼ継続的なフルバックアップが必要になります。

CohesityとRPO (目標復旧時点)

デジタルのビジネス運営における24時間365日の性質やスピードは、RPO (目標復旧時点) を限りなくゼロに近づけるために (理想的には、時間単位や日単位ではなく、分単位または秒単位)、できることは何でもやらなければならないことを意味しています。

しかし、従来の災害復旧やデータ保護製品へ多額の投資を行っているのにもかかわらず、企業では未だに想定外のダウンタイムが発生し、多くの場合、売上の損失、コンプライアンスやデータ漏洩に対する違反や罰金、従業員の生産性低下といった形で、直接的または間接的な損失に繋がっています。

このようなビジネスへの悪影響は、データ保護計画でその目的を達成できない場合、顧客や従業員からの信頼が失われることでさらに悪化します。しかしRPOを改善しようとする場合、非常に多くの企業が、常時オンの企業をサポートするために継続的なメンテナンスが必要となる、高価で複雑なポイントソリューションを導入しています。

Cohesityはエンドツーエンドのインフラ (ターゲットストレージ、バックアップ、レプリケーション、災害復旧、クラウド階層化など) を統合することで、従来のデータ保護製品の複雑さを解消する業界唯一の包括的なデータセキュリティとデータ管理プラットフォームを提供しています。これにより、重要なアプリケーションとデータのRPOを限りなくゼロに近づけるために必要となる、あらゆるソリューションとツールを手に入れることができます。

計画外のシステム停止が発生した場合でも、Cohesityのアーキテクチャであれば数百台のVM (仮想マシン) を即座に復旧させることができます。このインスタントマスリストア機能があれば、世界中の企業がSLO (サービスレベル目標)を達成できるようになります。

またCohesityでは、任意のバックアップポイントからすべてのミッションクリティカルなVMを復旧させることができます。しかも、それが災害の発生する数秒前であっても復旧可能です。

Cohesityのソリューションは次のような機能を提供するため、企業は予測通りにSLOを達成することができます:

  • ほぼゼロのRPOを達成し、最新バージョンまたは任意のバックアップポイントにリストアする能力
  • 追加の製品やポリシーの管理を必要としない統合ソリューション
  • 既存のバックアップポリシーを補完するシンプルなオペレーション
  • レプリケーションとアーカイブが可能なバックアップデータ
X
Icon ionic ios-globe

英語版のコンテンツを見ようとしています。このまま続けますか?

この警告を再度表示しないでください

Icon ionic ios-globe

英語版のコンテンツを見ようとしています。このまま続けますか?

この警告を再度表示しないでください