RTO(Recovery Time Objective:目標復旧時間)は、障害による中断から、定めた水準まで業務やシステムを復旧させる時間の目標です。RPOが扱うデータの損失範囲とは分けて考えます。
RTO=2時間を具体例で理解
14時にサービスが停止し、RTOが2時間なら、16時までに決めたサービス水準へ復旧することを目指します。15時30分に復旧した場合、実際の所要時間は1時間30分です。RTOそのものが、実際にかかった時間を表すわけではありません。
| 項目 | この例での内容 |
|---|---|
| 中断の発生 | 14時 |
| RTO | 2時間 |
| 目標期限 | 16時 |
| 実際の復旧 | 15時30分なら所要1時間30分 |
「何を復旧とするか」を決める
サーバーが起動しただけで、必要な業務が再開できるとは限りません。データの復元、アプリケーションの起動、接続先の切替、動作確認などを含め、どの水準を復旧完了とするかを先に定めます。中断の検知から対応開始までの遅れも、目標の達成に影響します。
RPOとの違い
| 指標 | 見る対象 | 例 |
|---|---|---|
| RTO | 中断から復旧までの時間 | 2時間以内に再開 |
| RPO | 許容するデータ損失の時間幅 | 最大1時間分の更新損失を許容 |
短時間で起動しても、古いデータしか戻せなければRPOを満たさない場合があります。反対に最新に近いデータを保全できても、復旧が遅ければRTOを満たしません。詳しくはRPOの記事も確認してください。
RTOを満たすために何を準備する?
復旧手順の整備、自動化、代替環境、バックアップからの復元方法などを検討します。バックアップ取得の速さと復旧の速さは別です。増分バックアップの適用や、システム間の依存関係まで含めて訓練し、実測時間を目標と比較します。
最短時間や業種別の固定値ではない
RTOは技術的に出せる最速の数字ではなく、業務影響と費用・実現性を踏まえて合意する目標です。業務が停止に耐えられる限界と同じものとして機械的に置かず、再開後に必要な作業も考えます。業種だけで一律の値を決めないことが大切です。
確認問題
10時に停止し、RTO=3時間、実際の再開は12時でした。RTOは達成していますか?また、失われたデータの時間幅は分かりますか?
解答・解説を見る
所要2時間なので、定めた水準で復旧できていればRTOを達成しています。データの復旧時点は示されていないため、損失の時間幅やRPOの達成状況は分かりません。
バックアップと復旧目標をnoteで復習
無料noteではRTOとバックアップ方式の関係を説明しています。フル・差分・増分で復旧に何が必要かを確認し、取得と復旧の両面から復習できます。
ほかの教材は資格・目的別のnote教材ナビから選べます。

コメント