バックアップから本当に戻せる？ RTOとRPOを復旧時刻で検証する

公開・確認：2026年10月16日／作成：FE Study編集部

この実習でできるようになること

RPOを失う可能性のある更新の期間、RTOを復旧までの時間として分けられる。
選んだ完全・差分バックアップと、必要なログのつながりを説明できる。
検知・判断・動作確認も含めて、目標内に再開できるかを検算できる。

前提と課題

架空の受注システムが火曜日10:40に停止し、稼働中のデータベースへアクセスできなくなりました。業務側と合意した目標は、RTOが120分、RPOが15分です。この演習ではRTOの起点を停止した10:40、復旧完了を「整合性と主要業務の動作を確認して利用再開できた時点」と定義します。

独立した保管先から完全・差分バックアップと10:30までのログを取得できます。10:35以降のログは利用不能です。全ての復元作業は直列に進み、所要時間は復元訓練で確認済みという演習上の設定です。実在するシステムでの実測値ではありません。データベース製品が対応する整合性のあるバックアップと、有効なログ列がそろっていることを前提にします。

停止時刻と目標: 火曜10:40停止／RTO 120分／RPO 15分
完全バックアップ: 日曜00:00時点。復元に40分。
差分バックアップ: 火曜00:00時点。日曜の完全取得以後の変更を含む。復元に15分。
ログと作業: 10:30までの連続したログの適用10分。検知・判断10分、環境準備15分、検証20分。

自分で求めてみよう

どのデータをどの順に戻すか、どの時点まで復元できるか、利用を再開できる時刻を求めてください。今回の結果がRTO・RPOを満たすかを別々に判定し、目標を将来も守るために必要な確認を挙げましょう。

途中の式や表も紙に書いてから、次の手順と照合してください。

途中の手順と検算

1. 目標を二本の時間軸に書き直す

RTOは停止から復旧までに許容する時間なので、期限は10:40＋120分＝12:40です。バックアップを読み終えた時刻ではなく、合意した復旧完了の条件を満たした時刻で判定します。検知や判断に費やした時間も、停止後なら時計は進んでいます。

RPOは失ってよい更新の期間の目標です。停止10:40から15分戻った10:25以降の時点へ復元できれば、この事例の目標を満たします。復旧が早くても前日のデータにしか戻せなければRPOに失敗し、最新データに戻せても再開が翌日ならRTOに失敗します。二つは別の条件です。

1. 目標を二本の時間軸に書き直すの確認表
評価	今回の判定基準	比較する値
RTO	12:40までに利用を再開	停止から実際の復旧完了まで
RPO	10:25以降へデータを復元	停止時刻と復元可能時点の差

2. 完全、最新の差分、連続するログを選ぶ

まず日曜00:00の完全バックアップを戻し、その完全バックアップを基準とする火曜00:00の差分を適用します。差分は基準の完全取得以後の変更を含むため、この条件では月曜分の差分を順番に適用する必要はありません。増分方式と取り違えず、バックアップの種類と基準を確認します。

続いて火曜00:00の状態から10:30まで進めるために、製品の復旧手順で必要な連続したログを適用します。「10:30のファイル一つ」だけで足りるという意味ではありません。途中の必須ログが欠けていれば、その先まで進められない場合があります。バックアップの一覧に時刻が載っているだけでなく、復元できる組合せとログのつながりを検査します。

3. 復元可能時点から、失う可能性のある期間を計算する

今回の最後の利用可能なログで10:30時点まで戻せるので、停止10:40との差は10分です。目標の15分以内なので、今回のRPOは満たします。ただし10:30から10:40までの更新は復元対象に含まれず、実際に失われる取引件数はその間の処理記録を調べなければ分かりません。時間だけから件数を推定しないでください。

もしログを使えず火曜00:00の差分までしか戻せなければ、失う可能性のある期間は10時間40分です。バックアップが取得できている事実だけでは、RPOを満たしたことになりません。また今回は10分という実績でも、今後の全ての障害で15分以内を保証したことにはならず、取得間隔、転送遅延、保存先の障害も見直す必要があります。

4. 復元の前後を含め、利用再開までの所要時間を足す

検知・復旧判断10分、隔離された復旧環境の準備15分、完全40分、差分15分、ログ10分、整合性と主要業務の確認20分を足すと110分です。全て直列という前提なので単純に合計します。再開は10:40＋110分＝12:30で、RTO期限12:40に対して10分の余裕があります。

データの読込み完了は12:10ですが、確認を省いてこの時刻を復旧完了とはしません。受注の参照・登録、金額や件数の整合性、アクセス制御など合意した項目を確認し、業務側が再開を承認します。検知・判断が25分へ伸びると全体は125分、再開12:45となってRTOを5分超えます。復元ソフトの速度以外にも改善の余地があります。

4. 復元の前後を含め、利用再開までの所要時間を足すの確認表
作業	所要時間	終了時刻
検知・判断	10分	10:50
復旧環境準備	15分	11:05
完全バックアップ復元	40分	11:45
差分の適用	15分	12:00
ログの適用	10分	12:10
整合性・業務確認	20分	12:30

5. 復元訓練を、目標を検証する仕組みにする

バックアップ取得の成功通知は、復元成功の証拠ではありません。復号鍵、権限、復旧先の容量、ソフトウェアの互換性、ログ列の欠落によって、取得済みでも戻せないことがあります。隔離した環境で実際に復元し、件数・主要データ・業務操作を検査して、手順と所要時間を更新します。

稼働系とバックアップが同じ認証情報や削除権限に依存していると、一度の侵害で両方を失うおそれがあります。保存先と権限の分離、保持期間、変更や削除への対策、必要な鍵の保管を検討します。複製があっても誤更新や暗号化が即座に複製される可能性があるため、戻せる過去の時点を保持する仕組みも必要です。

解答と、ここまでの要点

日曜の完全バックアップ、火曜00:00の差分、そこから10:30まで進める連続したログを順に使います。復元可能時点10:30と停止10:40との差は10分で、今回のRPO 15分を満たします。

停止から再開まで110分、再開12:30なのでRTO 120分を満たし、余裕は10分です。これは提示した作業時間と利用可能なデータによる今回の評価で、将来の保証には継続的な復元訓練と条件の確認が必要です。

つまずいたときに確認すること

RPOを「復元にかかる時間」として、RTOと混同する。
差分と増分を取り違え、必要なバックアップやログの組合せを確認しない。
検知・判断・環境準備・業務確認を所要時間から外す。
バックアップの取得成功や複製の存在だけで、目標内に戻せると判断する。

条件が変わっても説明できますか？

選択後に結果と理由を確かめられます。解答は折りたたみからいつでも読めます。

停止10:40、RPO 15分です。目標を満たす復元可能時点のうち、最も古い時点はどれですか。10:1510:2512:40

選んでから確認できます。確認問題は通常の演習記録には加算しません。

解答と理由を見る

解答：10:25

10:40−15分＝10:25です。10:25より前へしか戻せないと、失う可能性のある期間が15分を超えます。12:40はRTOの復旧期限で、復元するデータの時点ではありません。

他の作業が同じまま、検知・判断が10分から25分へ伸びました。RTOの判定はどれですか。110分のままで、10分の余裕がある。125分になり、5分超過する。データを10:30まで戻せるのでRTOも満たす。

選んでから確認できます。確認問題は通常の演習記録には加算しません。

解答と理由を見る

解答：125分になり、5分超過する。

元の110分に増えた15分を足して125分です。12:45再開となり、期限12:40を5分超えます。復元可能時点が同じでも、RTOの成否は別に判定します。

次の学習

手順を見ずにもう一度解き、以下の関連問題でも同じ考え方を使えるか確かめましょう。

この分野の演習へ基礎知識を確認する別の実習を選ぶ

参照資料とケースの範囲

計算条件、表、シナリオ、確認問題は本サイト独自のものです。用語と考え方の確認には以下の一次資料を使っています。実務では組織の手順や実際の製品仕様も確認してください。

NIST SP 800-34 Rev.1：Contingency Planning Guide（RTO・RPO、バックアップ、復旧訓練） ↗

教材の根拠・編集方針／誤り・改善点を連絡する