RTO (Recovery Time Objective) vs. RPO (Recovery Point Objective),そして災害復旧計画

RTO(Recovery Time Objective：目標復旧時間)は、ビジネス継続性(BCP)を維持するために、災害後にITインフラとサービスを復旧する必要がある時間を計算するのに役立つ測定基準です。

RPO(Recovery Point Objective：目標復旧ポイント)は、失われるデータの最大許容量の測定値です。また、ビジネスに深刻な損害を与えることなく、最後のデータバックアップから災害までの時間を測定するのにも役立ちます。 RPOは、データバックアップを実行する頻度を決定するのにも役立ちます。

回復目標の違い

RTOとRPOはどちらも、データバックアップを実行する頻度の計算に役立つビジネス測定基準です。ただし、いくつかの重要な違いがあります。

評価基準：
RTOは、ビジネス全体のニーズを反映しています。これは、ITインフラとサービスが中断した状態でビジネスが存続できるかの期間指標です。対照的に、RPOはデータに関するものです。データをバックアップする頻度を決定し、他のITニーズは反映しません。

コストとの関連性：
要求の厳しいRTOの維持に関連するコストは、詳細なRPOのコストよりも高くなる場合があります。これは、RTOがデータだけでなく、ビジネスインフラ全体のコストが含まれるためです。

自動化：
RPOの目標を達成するには、適切な間隔でデータのバックアップを実行する必要があります。データのバックアップは簡単に自動化できるため、自動化したRPO戦略の実装は簡単です。一方、RTOはすべてのITオペレーションの復元を伴うため、より複雑です。完全に自動化された方法でRTOの目標を達成することは事実上不可能です。しかしユーザは回復プロセスをできるだけ自動化する必要があります。

計算が簡単：
いくつかの点で、RPOは、データの使用が比較的一貫しており、変数が少ないため、実装が簡単です。復旧時間にはデータだけでなく操作全体が含まれるため、さらに複雑になります。復旧時刻は、災害が発生した時刻や曜日などの要因に基づいて変化する可能性があります。一方RTOは、IT組織で可能なことを整合する必要があります。可能な最小復旧時間が2時間である場合、1時間のRTOでは決して満たされません。管理者は、さまざまな種類の復旧を実行できる速度を十分に理解している必要があります。そうして初めて、経営のニーズに基づいて、RTOを適切に調整し、対応することができます。

RTO、RPO、そして災害復旧計画：
災害後のビジネスの存続を保証し、費用対効果の高い災害復旧計画を作成するには、RTOとRPOの両方を検討する必要があります。災害から効果的に回復するには、RTOとRPOの両方の目標を確実に達成できる必要があります。

同時に、コストを節約するために、RTOおよびRPO保証への過剰な投資を避ける必要があります。たとえば、ビジネスのRTOが4時間で、ITインフラが2時間の復旧時間に対応できる場合、ハードウェア/ソフトウェアにさらに多額の投資を行って最小復元時間を1時間に短縮することは現在のビジネスニーズではありません。

1 RTOとRPOをレベルアップするためのヒント
2 ビデオ「災害対策BCPのすゝめ」を準備しております。ご視聴希望の方はご連絡ください。
3 参考資料：仮想化ディザスタリ・リカバリ・プランのエッセンシャル・チェックリスト

RTOとRPOをレベルアップするためのヒント

(1)バックアップ・ソリューションを確認する
バックアップ・パラメータは重要です。複数のバージョンを提供する信頼性の高いソリューションを探すことと、保持計画が少なくとも90日間遡ることが最善の選択肢です。パラメータとともに、ミッションクリティカルなデータのスナップショットの数を増やすことも検討してください。

(2)プロセスの微調整
データを配置し、バックアップのスケジュールを設定しても、回復プロセスがスムーズに進むとは限りません。手元にハードウェアがない場合や、チームメンバーが回復プロセスに関する知識を持っていない場合があります。これらにより回復時間が長くなる可能性があるため、事前にプロセスを確認して微調整することを検討してください。

(3)予算の管理
より多くのスナップショットとバージョンを保持するには、より多くのストレージ容量と容量が必要になるため、より多くの費用も必要になります。コストを削減するために、一部のバージョンをローカルストレージに保持することを検討してください。

(4)3-2-1 ルール
少なくとも3つのデータのコピーを2つの独立したストレージメディアに保存し、1つのデータのコピーをオフサイトに保存すると、いずれかのストレージの場所にアクセスできなくなった場合でもデータを救うことができます。

(5)災害復旧（DR)計画を立てる
バックアップだけでは十分ではありません。十分に検討されたDR計画を作成し、考えられるすべての災害シナリオを含めます。最悪のシナリオについて考え、それらに備えてください。

(6)テスト、テスト、テスト
災害復旧戦略を絶えずテストして、その問題点を明らかにします。ボトルネックを理解し、計画を微調整することが、将来の重大な障害を回避するのに役立ちます。

ビデオ「災害対策BCPのすゝめ」を準備しております。ご視聴希望の方はご連絡ください。

問い合わせ： https://www.climb.co.jp/soft/contact/contact.php

参考資料：仮想化ディザスタリ・リカバリ・プランのエッセンシャル・チェックリスト

https://www.slideshare.net/climb_soft/ss-15547971