RPO（Recovery Point Objective＝目標復旧時点）は、障害時にどこまでのデータ損失を許容するかを表す指標です。「何分前・何時間前の状態まで戻れれば業務が成り立つか」を決めるときに使います。
重要なのは、RPO はバックアップ間隔とほぼ同義になるという点です。1日1回しか取っていなければ、最悪24時間分の入力が消えることを受け入れる、という意味になります。
まず押さえたいポイント
- 失ってよいデータの量（時間）の目標値
- 実質バックアップ頻度で決まる（1時間ごとに取るなら RPO は約1時間）
- 短くするほどコストと運用負荷が上がる
- 業務ごとに違ってよい（受注データは短く、ログは長くてよい等）
近い用語との違い
必ずセットで語られるのが RTO です。RPO は「どこまで戻れるか（失うデータ量）」、RTO は「どれだけ早く復旧するか（停止時間）」で、測っているものが違います。RPO＝時間軸の後ろ向き、RTO＝時間軸の前向きと覚えると混同しません。
押さえておきたい注意点
RPO をゼロに近づけるには、バックアップではなくレプリケーションなど常時複製の仕組みが必要になり、費用も設計難度も跳ね上がります。理想値だけ決めても運用が追いつかなければ意味がないので、「業務が耐えられる損失」から逆算するのが実務的です。
実務で見るポイント
データ種別ごとに RPO を決め、それを満たすバックアップ頻度になっているかを実測します。宣言だけして実際は日次、という乖離がよくある失敗です。設計の考え方は バックアップはあるのに戻せないを防ぐには？ も参考になります。
決め方は「その時間分のデータが消えたら、業務は何をやり直すことになるか」から逆算するのが実務的です。たとえば受注が1日100件なら、日次バックアップは最悪100件の再入力を意味します。これが許容できないなら頻度を上げる、という順番で考えると、コストの議論が具体的になります。