先に要点
- RPO は「どこまで戻れるか」、RTO は「どれだけ早く戻せるか」です。NIST の定義では、RPO は障害後にデータを復旧すべき時点、RTO は業務に悪影響が出る前に復旧を終えなければならない長さとされています。
- 2つは別の制約から決まります。RPO の上限は取得の間隔で決まり、RTO の下限は実際に復元にかかる時間で決まります。同じ数字を目標にしても、詰まる場所が違います。
- 片方だけ厳しくしても効きません。1時間ごとに取っていても、戻すのに半日かかるなら停止は半日です。逆に復元が速くても、1日1回しか取っていなければ最大1日分が消えます。
- 決め方の順序は業務が耐えられる線を先に決め、手段は後から選ぶです。手段から入ると、足りないか過剰になります。
バックアップの設計で最初に詰まるのが、この2つの数字です。何時間なら許されるのかを決めないまま、取得の間隔や保管先を選ぼうとすると、根拠のない設定になります。
この記事では、2つが何を指すのかを公式の定義で確認したうえで、それぞれをどこから決めるのかと、決めたあとに何が縛られるのかを整理します。
2つの定義
アメリカの標準化機関 NIST の定義がはっきりしています。
- RPO（Recovery Point Objective）は「障害の後にデータを復旧すべき時点」
- RTO（Recovery Time Objective）は「組織の業務に悪影響が出る前に、復旧の段階を終えていなければならない全体の長さ」
言い換えると、RPO は失ってよいデータの量、RTO は止まってよい時間です。単位はどちらも時間ですが、測っているものが違います。
図にすると分かりやすい
時間軸で並べます。障害が起きた瞬間を境に、左右で別の話になります。
| 位置 | 何を表すか | 決めるもの |
|---|---|---|
| 障害の前を向いている | 最後に取った複製から障害までの間 | RPO。この幅の分だけデータが消える |
| 障害の後を向いている | 障害から復旧完了までの間 | RTO。この幅の分だけ業務が止まる |
RPO は過去に向かって、RTO は未来に向かって測ります。ここを取り違えると議論が噛み合いません。
RPO はどこから決まるか
上限を決めているのは取得の間隔です。1日1回しか取っていなければ、RPO は最大24時間より短くできません。
だから設計はこの順になります。
- 「何時間分の入力を失ったら業務が成立しないか」を業務側に確認する
- その時間より短い間隔で取得する
- 世代と保管期間を決める
2番だけを先に決めがちですが、根拠は1番にしかありません。「とりあえず日次で」は、失ってよい量を決めていないという意味です。
⚠️ もう1つ注意があります。異常に気づくまでの時間より保管期間が短いと、気づいたときには全世代が汚染されています。RPO を短くするだけでは足りず、どこまで遡れるかも別に必要です。
RTO はどこから決まるか
こちらの下限を決めているのは実際に復元にかかる時間です。そしてこれは測らないと分かりません。
手順書に書いてある時間ではなく、実際にやってみた時間で決めます。含めるものは次のとおりです。
- 障害だと判断するまでの時間
- 復元する対象を選ぶまでの時間
- データを転送して戻す時間
- 戻った内容が正しいか確認する時間
- 業務を再開してよいと判断するまでの時間
データを戻す時間だけを RTO と見なすと、必ず足りなくなります。判断と確認の時間が入っていないからです。
片方だけ詰めても効かない
よくある食い違いです。
| 状況 | 実際に起きること |
|---|---|
| 1時間ごとに取得。復元に半日 | データは1時間分しか失わないが、業務は半日止まる |
| 復元は10分。1日1回の取得 | すぐ戻るが、最大1日分の入力が消えている |
2つは掛け算ではなく、それぞれが独立した痛みです。どちらが業務にとって重いかは、システムによって違います。受注を取りこぼす業務なら RPO、止まると現場が動けない業務なら RTO が先に来ます。
決めた数字が縛るもの
数字を決めると、選べる手段が絞られます。ここが実務で効いてくる部分です。
- RPO を分単位にしたいなら、定期的な取得では足りません。継続的な複製の仕組みが要ります
- RTO を分単位にしたいなら、戻す作業では足りません。すぐ切り替えられる待機側が要ります
- どちらも緩くてよいなら、安い保管先へ日次で取るだけで足ります
順序が逆になっている設計をよく見ます。手段を先に選んでから「これで何時間ですか」と聞くと、答えは出ますが、それが業務の許容範囲かどうかは誰も確認していません。
数字は1つに決めなくてよい
システム全体で同じ値にする必要はありません。同じサービスの中でも、データの種類ごとに分けた方が現実的です。
- 取引の記録は失えないので RPO を短く
- 生成し直せるキャッシュや画像の変換結果は、RPO を長くしてよい
- 設定ファイルは量が小さいので、頻度を上げても負担にならない
全部を一番厳しい値に揃えると、費用だけが増えます。分けることで、厳しくすべき場所に予算を寄せられます。
RTOとRPOに関するよくある質問
Q. 目標を決めても達成できているか分かりません。
復元のリハーサルで測ってください。RTO は測定値です。手順書の想定ではなく、実際にかかった時間を記録して、目標と比べます。1回やると想定の何倍もかかることが珍しくありません。
Q. RPO をゼロにはできませんか？
理屈の上では継続的な複製で近づけられますが、複製が同期している相手も一緒に壊れる障害があります。そのためゼロを名乗る構成でも、別に切り離した複製は必要です。バックアップと冗長化は役割が違います。
Q. 誰が決める数字ですか？
技術側だけでは決められません。失ってよいデータ量と止まってよい時間は業務の判断です。技術側の役割は、その値を実現する手段と費用を示し、無理な値なら無理だと伝えることです。
Q. クラウドなら自動で守られていますか？
基盤の冗長化と、自分のデータの復旧は別です。誤って消したデータや、誤った更新で壊れたデータは、基盤の冗長化では戻りません。提供側の責任範囲を確認したうえで、自分で取る分を決めてください。
まとめ
RPO は過去に向かって「どこまで戻れるか」、RTO は未来に向かって「どれだけ早く戻せるか」です。上限を決めるのは取得の間隔、下限を決めるのは復元の実測時間で、詰まる場所が違うので片方だけ詰めても効きません。
進め方は1つです。業務が耐えられる線を先に決め、手段は後から選ぶ。そしてRTO は必ず一度測る。測っていない目標は、目標ではなく願望になります。