RPOとは？ わかりやすく10分で解説

RPOとは

RPO（Recovery Point Objective）は、障害や災害のあとにどの時点までデータを戻せれば業務を再開できるかを示す目標値です。実務では、許容できるデータ損失を時間で表す指標として使われ、BCPやDRでバックアップ頻度、復旧方式、運用体制を決める基準になります。

たとえば障害が14:00に発生し、RPOが4時間なら、10:00時点までのデータを復旧できる状態を目標にします。ここで大事なのは、RPOは希望値ではなく、実際のバックアップ取得間隔、レプリケーション方式、復旧手順、担当体制まで含めて達成できる値でなければならないことです。

まず押さえたいのは、RPOだけでは復旧設計は決まらないという点です。データをどこまで戻せるかに加えて、RTOのように「いつまでに再開するか」も合わせて決めないと、業務として成立する復旧計画にはなりません。

RPOが示すもの

RPOは、障害時に失ってよいデータ量の上限を時間で表したものです。受注、決済、在庫更新、顧客対応履歴のように更新頻度が高い業務では、RPOが長いほど再入力や整合性確認の負担が増えます。反対に、更新が少ない参照中心の情報では、比較的長いRPOでも許容できることがあります。

RPOが重要になる場面

RPOが問題になるのは、地震や停電による拠点停止、ストレージ障害、人的ミス、ランサムウェア被害などで、直近データを失う可能性がある場面です。業務側が「何時間分までなら失っても再処理できるのか」を決めていないと、復旧時に判断がぶれ、再開までの時間も延びやすくなります。

RPOとRTOの違い

RPOとRTOは似た言葉ですが、見ている対象が違います。RPOはデータ損失、RTOは停止時間の目標です。どちらか一方だけを決めても、復旧計画としては不十分です。

たとえば、RPOが1時間でRTOが24時間なら、失うデータは1時間分までに抑えられても、業務再開は翌日になる可能性があります。逆に、RTOが1時間でもRPOが24時間なら、システムは早く立ち上がっても、前日以降のデータが戻らないかもしれません。業務が本当に困るのはどちらかを分けて考える必要があります。

RPOだけで判断しない方がよい理由

RPOを短く設定しても、復旧作業そのものに時間がかかれば業務停止は長引きます。また、RPOを満たす仕組みがあっても、依存する認証基盤、ネットワーク、DNS、業務アプリが同時に戻らなければ再開できません。復旧計画では、データ単体ではなく業務全体の依存関係を見ることが欠かせません。

RPOはどう決めるか

RPOは「短いほど良い」で決める指標ではありません。短くするほど取得回数、保管先、回線、監視、テストの負荷が上がるため、業務影響と運用負荷の釣り合いで決めます。

1. 重要業務と重要データを切り分ける

最初に行うのは、ビジネス影響分析（BIA）の考え方で、どの業務が止まると困るのか、その業務で失ってはいけないデータは何かを整理することです。受注や会計のように後から再作成しにくいデータと、再取得できる参照データでは、求めるRPOを同じにしない方が現実的です。

2. データ損失の影響を時間に置き換える

「データが消えると困る」という表現だけでは、RPOは決まりません。1時間分の再入力なら吸収できるのか、半日分の取引欠落は許容できないのか、といった形で時間に落とし込む必要があります。ここが曖昧だと、障害時に復旧の基準がぶれます。

3. 現行方式で達成できるかを確認する

バックアップだけで戻す設計なのか、レプリケーションを使うのか、スナップショットを併用するのかで、実現できるRPOは変わります。バックアップ中心の構成では、取得間隔が実効RPOの目安になりやすく、より短いRPOが必要なら別方式の検討が必要です。

4. 復旧テストで実効性を確認する

RPOは設定値を書くだけでは成立しません。実際に復旧してみて、どの時点まで戻せたのか、復旧対象の選択や順序で詰まらないかを確認して初めて、現実の目標値になります。バックアップが成功していても、復旧できなければRPOを満たしたことにはなりません。

RPO設定の目安を考えるときの観点

• 業務の重要度：止まると売上、顧客対応、法令対応にどの程度影響するか
• データの再現性：再入力や再取得ができるか、できても負担が大きすぎないか
• 更新頻度：1時間ごとに変わるのか、1日単位でしか変わらないのか
• 復旧方式：バックアップ、スナップショット、レプリケーションのどれで戻すのか
• 保管場所：同一拠点だけか、別拠点やクラウドにも保持するのか
• 運用体制：夜間や休日も監視できるか、復旧担当を呼び出せるか

同じ会社の中でも、基幹系、情報系、開発系、保管系で適切なRPOは変わります。全システムを一律に短いRPOへ寄せると、費用だけが増え、守るべき対象の優先順位がかえって見えにくくなります。

RPOを小さくする主な方法

バックアップ取得を高頻度化する

もっとも基本的な方法は、バックアップの取得間隔を短くすることです。ただし、フルバックアップを高頻度で回すと処理時間やネットワーク負荷が大きくなります。必要に応じて差分バックアップや増分バックアップを組み合わせ、負荷と復旧性の両方を見ます。

スナップショットやレプリケーションを使う

数分単位のRPOを求める場合、定期バックアップだけでは厳しいことがあります。その場合はスナップショットの取得間隔を詰める、非同期レプリケーションで別系統へ継続反映する、といった方法を検討します。さらに厳しい要件では、同期レプリケーションでRPOを限りなく小さくする設計もありますが、性能、回線、距離、コストの制約が強くなります。

保管先を分ける

RPOを満たすデータが残っていても、同じ障害で一緒に失われれば意味がありません。同一拠点内だけの保持では、拠点障害や権限侵害の影響を同時に受けることがあります。取得頻度だけでなく、どこに保持するかまで含めて設計します。

監視と復旧訓練を運用に組み込む

バックアップ失敗の検知、世代管理、復旧手順の更新、定期的な復元テストが回っていないと、RPOは名目値のままです。担当者が変わっても同じ手順で復旧できる状態まで標準化しておく必要があります。

RPO設定で起こりやすい失敗

• 目標だけ短くして仕組みが追いつかない： 業務側の期待値だけが上がり、実障害で守れない
• 全システムを同じRPOにする： 重要度の差が消え、投資配分を誤りやすい
• バックアップ取得の成功だけを見る： 実際に復旧できるかを確認していない
• 依存関係を無視する： データは戻っても、周辺システムが使えず再開できない
• 平時の再処理負担を見積もらない： 障害後の手作業が想定より重くなる

RPOを決めるときの要点

RPOは、障害時にどの時点までデータを戻せればよいかを示す目標値です。短く設定すれば安心という話ではなく、業務が許容できるデータ損失、実際に採れる保護方式、復旧手順、運用体制をそろえて初めて意味を持ちます。

実務では、重要業務と重要データを分ける、許容できる損失を時間で決める、現行構成で達成できるか確認する、復旧テストで検証するという順で整理すると、無理のないRPOを決めやすくなります。RPOとRTOを切り分けて考え、どちらの不足が業務継続を止めるのかを見極めることが大切です。