ある組織では、ある業務システムのBackupを毎日取得していました。
担当者は、次のように考えていました。
「毎日Backupしているのだから、RPOは1日程度だろう」
ある日、障害が発生しました。担当者はRestore作業を行い、業務システムが復旧するまでには、それなりの時間がかかりました。
担当者は、この復旧にかかった時間を見て、次のように考えました。
「この時間が、うちのRTOなんだな」
しかし後になって、担当者はあることに気づきます。RTOやRPOは、実際にRestoreにかかった時間や、Backupを何時間おきに取っているかという実装上の数字そのものではなく、業務上どこまでを目標とするかを示すものだったのです。
「毎日Backupを取っていること」と、「RPOが1日であると決まっていること」は、同じではありません。同じように、「実際にRestoreにかかった時間」と、「RTOという目標」も、同じではありません。
この章では、この違いについて整理していきます。
5.1 RTO/RPOは「目標」である
Chapter 4では、BIA（業務影響分析）によって、業務機能や中断時の影響を見ることが、Recoveryの必要性や優先度を考えるための基礎になることを見ました。
この章では、その復旧の必要性を、より具体的な目標として表現する方法の一つを見ていきます。それが、RTO（Recovery Time Objective）とRPO（Recovery Point Objective）です。
ここで大切な前提があります。
RTO/RPOは、「実際に何時間かかったか」や「Backupを何時間おきに取っているか」を表す言葉ではありません。業務上、どこまでを目標とするかを表す言葉です。
つまり、RTO/RPOはまず「目標」であり、それを実現するための技術的な設計や、実際に達成された結果とは、別のものとして考える必要があります。この区別については、5.7で改めて整理します。
5.2 RTOとは何か
RTO（Recovery Time Objective、目標復旧時間）とは、障害や中断が発生したあと、どの程度の時間内に業務やシステムを復旧させる必要があるかを考えるための目標です。
米国国立標準技術研究所、NIST（National Institute of Standards and Technology）が公開している情報システムの復旧計画に関する技術文書でも、RTOは、許容できない停止時間や業務影響と結びついた復旧時間の目標として扱われています。
ここで気をつけたいのは、RTOが「復旧までにかかってよい最大時間」を業務側の視点から考えるものだという点です。技術的にどのように復旧作業を進めるか、実際にどれくらいの時間がかかるかという話とは、いったん切り離して考えます。
この章では、RTOが正確にどの瞬間から始まり、どの瞬間に終わるとみなすかという、厳密な時間の区切り方までは扱いません。まずは、「業務上許容できる停止時間の目標」という考え方を押さえておければ十分です。
5.3 RPOとは何か
RPO（Recovery Point Objective、目標復旧時点）とは、障害が発生したときに、どの時点までデータを戻せる必要があるか、どの程度のデータ損失まで許容できるかを考えるための目標です。
こちらもNISTの技術文書で、許容できるデータ損失と結びついた、復旧すべき時点の目標として扱われています。
RPOは、「Backupとバックアップの間隔（Backup interval）そのもの」ではありません。「どの程度のデータ損失まで業務上許容できるか」という目標です。
例えば、「RPOが1時間」という目標は、「障害発生時点から遡って、最大でも1時間分のデータ損失までは許容する」という意味であり、「1時間おきにBackupを取っている」という実装上の事実そのものではありません。
5.4 RTOとRestore所要時間は同じではない
ここで、よくある誤解を整理しておきます。
RTOは目標であり、実際のRestoreやRecoveryにかかる時間（所要時間）そのものではありません。
冒頭のシナリオのように、「実際に復旧にかかった時間」を、そのままRTOだと考えてしまうことがあります。しかし、これは順序が逆です。RTOは、あらかじめ業務側が「このくらいの時間内に復旧させたい」と考える目標であり、実際のRestore所要時間は、その目標を達成できたかどうかを判断するための、結果側の情報です。
ただし、ここで一つ注意が必要です。「RTOと実際のRestore所要時間は無関係」というわけではありません。実際のRestoreやRecoveryに要する時間は、RTOという目標を達成できるかどうかを判断するために重要な情報です。目標と実測値は、別の概念でありながら、互いに関係しています。
5.5 RPOとBackup intervalは同じではない
RPOについても、同じような整理が必要です。
RPOは目標であり、Backupを取得する間隔（Backup interval）そのものではありません。
「毎日Backupを取っているという事実だけでは、RPOが24時間であるとは決まりません。」
これは、冒頭のシナリオで担当者が最初に考えていたことでもあります。Backupの取得間隔は、RPOという目標を達成するための、設計上の一つの要素です。RPOという目標そのものではありません。
ここでも、「Backup intervalとRPOはまったく無関係」というわけではない点に注意してください。Backupをどのくらいの間隔で取得するかは、RPOという目標を実際に満たせるかどうかに影響する、design inputの一つです。目標と実装上の設定は、別の概念でありながら、互いに関係しています。
RTO / RPOと混同しやすいもの
ここまでの内容を、簡単な表として整理します。
| 用語 | 何を表すか | 混同しやすいもの |
|---|---|---|
| RTO | 復旧時間に関する目標 | 実測のRestore/Recovery所要時間 |
| RPO | 復旧すべきデータ時点に関する目標 | Backup interval / Backup frequency |
この表もあくまで整理のための目安であり、具体的な時間の数値や業界標準値を示すものではありません。
5.6 RTO/RPOを設計へつなぐ
ここまで見てきたように、RTOとRPOは、業務上の目標として、まず考えるべきものです。
その流れを簡単に整理すると、次のようになります。
業務影響 / 復旧の必要性（Chapter 4）
↓
RTO / RPOという目標
↓
Backup / Recovery設計への入力RTO/RPOという目標が定まると、それはBackupやRecoveryの設計を考えるための入力の一つになります。
例えば、Backupをどのくらいの間隔で取得するかといった設計上の判断も、RPOという目標と関係します。
具体的な技術設計には、このほかにも複数の要素が関係します。
ただし、これは「RTO/RPOという目標を決めれば、設計内容が自動的に一意に決まる」という意味ではありません。目標は、設計を考えるための材料や基礎になるものであり、具体的な設計判断そのものを機械的に導き出すものではありません。
なお、RPOで求める時点まで戻るためには、その時点へのRestoreが実際に成立する必要があります。これは技術的な依存関係の問題であり、詳しくはこの章の範囲を超えます。
5.7 目標と実際に達成できた結果を分ける
この章の内容を、もう一段階整理しておきます。
RTO/RPOについて考えるときは、次の3つの層を分けて考えると分かりやすくなります。
Teaching Diagram（簡略化した概念図であり、特定規格や製品の厳密な時間軸定義を
示すものではありません）
Recovery Objective（RTO / RPOという目標）
↓
Technical Design / Operation（Backup頻度、Restore方法などの技術的な設計・運用）
↓
Actual Measured Result（実際に達成された復旧時間・復旧できたデータ時点）RTOやRPOという目標を設定しただけでは、それを達成したことにはなりません。目標を踏まえて技術的な設計や運用を行い、実際に障害が起きたときにその目標を達成できるかどうかは、また別の確認が必要です。
RTOを考えるときには、何をもってRecovery完了とするかという基準も重要になります。この点は、後のRecovery plan章で扱います。
また、設定した目標が実際に達成できるかどうかは、Recovery Test / Exerciseによって確認する必要があります。具体的な確認の方法については、後の章で改めて扱います。
5.8 まとめ
この章では、RTOとRPOについて、それぞれが「目標」であるという考え方を中心に整理しました。
重要なのは、次の点です。
- RTOは、障害発生後どの程度の時間内に復旧させる必要があるかという、業務上の目標である。
- RPOは、どの時点までデータを戻す必要があるかという、業務上の目標である。
- RTOは実際のRestore所要時間そのものではないが、両者は無関係ではなく、目標達成の判断に関係する。
- RPOはBackup intervalそのものではないが、両者は無関係ではなく、目標達成に関係する設計要素の一つである。
- RTO/RPOという目標は、Backup/Recovery設計を考えるための材料・基礎になるが、設計内容を自動的に一意に決めるものではない。
- 目標を設定しただけでは達成したことにはならず、実際に達成できるかどうかはTest/Exerciseなどで確認する必要がある。
次の章では、業務の重要度（Business Criticality）、復旧の優先度（Recovery Priority）、そして技術的な復旧順序（Technical Recovery Order）が、それぞれ異なる考え方であることを見ていきます。
Chapter 5を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- RTOを自分の言葉で説明できますか。
- RPOを自分の言葉で説明できますか。
- RTOと実際のRestore所要時間が同じではない理由を説明できますか。
- RPOとBackup intervalが同じではない理由を説明できますか。
- RTO/RPOを設定しただけで達成したことにはならない理由を説明できますか。
すべて答えられなくても問題ありません。
むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。