RTOとRPO。BIA（事業影響度分析）から導き出される、事業継続計画における2大指標だ。この2つを理解せずして、災害復旧は語れない。

概要

両者とも、システム障害が発生した際の「どこまで許容できるか」を示す目標値だが、その尺度が異なる。

• RTO (Recovery Time Objective / 目標復旧時間)
  • システムが停止してから、復旧するまでの「時間」の目標値。「ダウンタイムは最大何時間まで許容できるか」を示す。
• RPO (Recovery Point Objective / 目標復旧時点)
  • 障害発生時に、どのくらい過去の時点までの「データ」が正常であれば許容できるか、という目標値。「最大で何時間分のデータ損失なら許容できるか」を示す。

具体例

ECサイトを例に取ろう。

• RTOが「1時間」なら、サイトがダウンしてから1時間以内にサービスを再開させなければならない、ということだ。これは、復旧作業にかけられる時間の上限を意味する。
• RPOが「15分」なら、障害直前の15分前までのデータは保証する必要がある、ということだ。これは、バックアップの頻度（少なくとも15分に1回）などを決定する。

タイムラインで理解する

障害発生時点を基準に考えると分かりやすい。

• RPOは、障害発生時点から「過去」に向かうベクトルだ。最後に正常だったデータ時点を指す。
• RTOは、障害発生時点から「未来」に向かうベクトルだ。サービスが復旧する時点を指す。

コストとのトレードオフ

RTOとRPOを短くすればするほど（ゼロに近づけるほど）、システムの可用性とデータの保護レベルは高まるが、そのためのコストは指数関数的に増大する。

• RTO/RPOが数日レベルなら、テープバックアップからの手動復旧で済むかもしれない。
• RTO/RPOが数分レベルなら、リアルタイムでデータを同期する高価なクラスタシステムやDRサイトが必要になる。

重要なのは、ビジネスの要求とコストのバランスを取り、業務ごとに最適なRTO/RPOを設定することだ。全てのシステムでゼロを目指すのは、非現実的で無駄な投資だ。

結論

RTOとRPOは、ビジネス部門の「ここまでなら耐えられる」という要求を、IT部門が実現すべき「技術的な目標」に翻訳するための共通言語だ。この2つの指標が、事業継続計画全体の設計思想とコストを決定づける。