基本情報のRTOとRPOの違いを時系列と例題で理解する

基本情報のRTOは「障害で止まったサービスを、どれだけの時間以内に復旧させるか」という目標です。RPOは「障害前のどの時点までデータを戻せるようにするか」という目標で、許容するデータ損失を時間で表します。どちらも時間を使いますが、見る対象が違います。

区別のコツは、障害発生時刻を真ん中に置くことです。そこから業務再開までを考えるのがRTO、そこから復旧するデータの時点へさかのぼるのがRPOです。「復旧まで30分」と「30分前のデータまで戻す」を分ければ、略語だけを暗記するより判断しやすくなります。

この記事では、時系列、業務で許容する範囲、科目Aを想定した自作例題で違いを確認します。例題の数字は説明用の仮定であり、実際の障害事例や製品の性能を示すものではありません。

基本情報のRTOとRPOを時系列で区別する

名前より先に見る対象を分ける

RTOはRecovery Time Objectiveの略で、日本語では目標復旧時間です。Timeに注目し、「サービスを再び使えるようにするまで、どれだけ待てるか」と読みます。復旧作業にかかった実績をそのまま名付ける言葉ではなく、事前に決める許容時間の目標です。

RPOはRecovery Point Objectiveの略で、目標復旧時点と呼びます。Pointに注目し、「データを時間のどこまで戻せればよいか」と読みます。目標を「障害の15分前」と表す場合も、「15分」という許容するデータ損失期間で表す場合もあります。後者でも、データを戻す処理に15分かけてよいという意味ではありません。

IPAの基本情報技術者試験シラバスVer.9.2では、サービス継続管理の用語例にRTO・RPO・RLOが挙がっています。機器を修理する話だけでなく、必要なサービスを継続・復旧するための目標として押さえましょう。

比較する点	RTO	RPO
日本語	目標復旧時間	目標復旧時点
判断する対象	サービスが使えない時間	復旧するデータの古さ
基本の問い	どれだけ早く再開するか	どこまでのデータを取り戻すか
目標の例	停止から60分以内に再開	障害の15分前以降のデータへ戻す

例えば、画面がすぐに表示されても、注文データが前日のものしか戻らなければ、データの目標を満たさない可能性があります。逆に、障害直前の注文がすべて残っていても、利用者が半日アクセスできなければ、停止時間の目標を満たさない可能性があります。再開の早さとデータの新しさを、二つの項目として扱うのが出発点です。

同じ障害を二つの時間軸で読む

説明用に、10時にサービスが停止し、10時40分に業務を再開したとします。復旧後のデータには9時50分までの更新が含まれ、9時50分を過ぎてから10時までの更新は戻せなかった条件です。このとき、実際の停止時間は40分、データが戻らなかった期間は10分です。

時刻の順序は「復旧したデータの時点9時50分→障害発生10時→業務再開10時40分」です。RPOを評価するときは左側の差、RTOを評価するときは右側の差を使います。同じ障害発生時刻を基準にしていても、終点は同じではありません。

時点・区間	この例の値	読み取れること
復旧したデータの時点	9時50分	ここまでの更新が戻った
サービス停止の開始	10時00分	停止時間の計測起点
業務再開	10時40分	停止時間の計測終点
停止から再開まで	40分	RTOの目標と比較する実績
データ時点から停止まで	10分	RPOの目標と比較する実績

ここで9時50分から10時40分までの50分を、RPOと考えないようにしてください。RPOが見ているのは、障害によって失われ得る障害前の更新です。再開まで待った40分は、別の停止時間として評価します。復旧作業を長くしても、戻せるデータの時点が自動的に古くなるわけではありません。

また、「9時50分」はデータが表す時点です。保存処理が終わった時刻や、ファイルを復元先へコピーし終わった時刻とは区別します。例えば9時50分時点の状態を保存し、転送が9時55分に終了した場合、保存完了の表示だけから9時55分までの更新を含むとは判断できません。設問にデータの対象時点が示されていたら、その値を使いましょう。

目標値と実際の結果を分ける

前の例で、事前の目標がRTO60分、RPO15分だったなら、停止40分は60分以内、データ損失期間10分は15分以内です。この条件では両方の目標を満たします。ここで「RTOが40分、RPOが10分に変わった」と書くより、「RTO60分に対して実績40分」と区別する方が、何を評価したのか明確になります。

もし目標がRTO30分、RPO15分なら、停止40分はRTOを超えますが、データ損失期間10分はRPOを満たします。片方の達成をもう片方へ広げないことが大切です。問題文が「両方の目標を満たすもの」を求めているなら、二つとも条件に収まる候補だけを選びます。

事前に決めた目標	同じ復旧結果	判断
RTO60分・RPO15分	停止40分・データ損失期間10分	両方を満たす
RTO30分・RPO15分	停止40分・データ損失期間10分	RTOのみ超過
RTO60分・RPO5分	停止40分・データ損失期間10分	RPOのみ超過

目標を満たすかの基本形は、実際の停止時間がRTO以下であり、復旧するデータの時点から障害までの差がRPO以下であることです。ただし、どの障害を対象にするか、どの機能まで復旧すれば完了かという条件も一致している必要があります。別の対象を測って出した短い数字では、業務の目標を達成した証拠になりません。

AWSのディザスタリカバリ目標の説明も、RTO・RPOを許容される最大値として整理しています。略語のObjectiveは目標という意味です。「実際には何分だったか」と「何分まで許容していたか」の二列を作ると、目標値と測定結果の混同を避けられます。

計測の起点と復旧完了をそろえる

本記事の時刻例では、RTOの計測起点をサービスが停止した時刻、終点を必要な業務を再開できた時刻とします。障害が起きた時刻、担当者が検知した時刻、復旧作業を始めた時刻が違う場合は、それぞれを別の欄に置きます。検知が遅れた時間を、都合よく停止時間から消さないためです。

例えば14時に停止し、14時10分に検知、14時20分に復旧作業を始め、14時50分に業務再開したとします。停止から再開までが計測対象なら50分です。作業開始からの30分だけを取り出すと、RTOの達成を判断する実績としては不足します。検知や担当者の判断にも時間がかかることが分かります。

復旧完了にも注意が必要です。サーバーが起動しただけで、利用者がログインできない、注文を登録できない、外部の決済先へ接続できない状態なら、業務が再開したとは言えない条件もあります。何をできる状態まで戻すのかを定めてから、その到達時刻を測ります。

一方、試験の問題文で「切替開始から利用可能になるまで」などの測定範囲が明示される場合は、その条件を優先します。RTOという名前を見て、どの資料でも必ず同じ工程を数えると決めつけないでください。実務の仕様でも、サービス全体の停止と、ある復旧工程の所要時間は、測定範囲を明記して区別する必要があります。

Microsoftの信頼性に関する解説は、RTOで扱うダウンタイムを仕様によって定義するとしています。学習では「問題文の起点と終点に線を引く」、実務では「誰がどの操作をできたら復旧とするかを決める」と考えると、同じ数字の意味をそろえやすくなります。

ゼロの意味とMTTRの違い

RPOが0という目標は、対象となるデータについて障害による損失を許容しないことを表します。障害直前までの必要な更新を戻す目標であって、サービスの停止を許容しないという意味ではありません。データを失わずに保持できても、利用先の切替や動作確認には時間がかかる場合があります。

説明用に、RPO0、RTO30分という要件を考えます。障害前に確定した対象データをすべて戻せて、停止から20分で必要な業務を再開したなら、この例の二つの目標は満たせます。20分止まったことだけで「RPO0を守れなかった」と判断するのは、停止時間とデータ損失を混ぜています。

ただし、RPO0と設定しただけで、あらゆる故障・誤操作・災害から必ずデータを守れるわけではありません。何を確定済みの更新として扱うか、どの障害を想定するか、復旧先までその更新が届くかという前提が要ります。「リアルタイム」という機能名だけで、どの状況でも損失ゼロと保証しないようにしましょう。

似た用語のMTTRは、複数の故障や中断に対する平均の修理・復旧時間を扱う指標です。RTOは、ある障害に備えて決めた許容時間の目標です。どちらも復旧の時間に関係しますが、「平均の実績」と「事前に決めた目標」を入れ替えてはいけません。

例えば三回の復旧時間が10分、20分、60分なら、その平均は30分です。平均が30分だからといって、RTO30分を三回とも守ったことにはなりません。60分の回は超過しています。平均値は傾向をつかむ材料であり、一件ごとの目標達成を示す数字ではないと分かりますね。

稼働率を求める式やMTBFとの関係は、基本情報の稼働率とMTBF・MTTRの計算で確認できます。本記事では、平均の復旧時間を求める話と、業務で許容する復旧時間を決める話が別だと押さえておけば十分です。

基本情報のRTOとRPOを業務要件と例題で判断する

業務の困り方から二つの目標を決める

RTOとRPOは、使いたい設備やバックアップ製品を選んでから名前を付けるだけの数値ではありません。先に業務が何に困るのかを整理し、許容できる停止と、取り戻せない更新の範囲を決めます。その後、構成や運用が目標に届くかを検討します。

例えば、注文受付のシステムで「停止が長いと新しい注文を受けられない」という問題はRTOの判断につながります。「直前の注文が消えると、支払いと発送の対応が合わなくなる」という問題はRPOの判断につながります。同じ注文業務でも、二つの損失の起こり方は違います。

日次の集計資料を翌朝までに作ればよい業務と、その場で受付結果を返す業務では、停止が与える影響は同じとは限りません。また、元の記録から再入力できる情報と、ほかに控えがない情報では、失われた更新を戻す負担が異なります。業種名だけで一律の目標を決めず、その業務の条件を見る必要があります。

業務の要求例	対応する考え方	確認すること
停止後30分以内に受付を再開	RTO	再開対象の受付機能と時間の起点
直近5分を超える更新の損失は不可	RPO	障害時点から戻るデータ時点の差
再開時は閲覧だけでもよい	復旧する機能・水準	登録や決済まで必要かを別途定義
月に平均して短く修理したい	平均値などの運用指標	一件ごとの復旧目標と区別

AWSの復旧要件のガイダンスでは、業務への影響と重要度を評価して目標を設定する考え方が示されています。厳しい目標ほど必要な備えが増える可能性がありますが、すべての業務へ同じ短い値を要求することが正解とは限りません。

RLOは、どの機能や水準まで戻すかという目標復旧レベルです。ここでは「何分までに」「どの時点のデータへ」に加えて、「何ができれば再開か」を指定する役割と捉えましょう。閲覧だけなら早く使えても、注文登録まで必要なら別の復旧時刻になることがあります。数字を比較する前に、同じ業務水準を指しているかを確かめます。

基本情報の文章問題では、「業務を早期に再開」「直前の取引を消失させない」「最低限の機能で再開」という表現を読み分けると、それぞれRTO、RPO、復旧レベルへつながります。すべてに「復旧」という語があっても、判断の対象まで同じとは限りません。

バックアップだけで達成を保証しない

バックアップ頻度はRPOを検討する材料ですが、その頻度だけで目標達成を保証できません。どの時点のデータが入っているか、正常に保存できたか、障害時にも読めるかを確認して、実際に戻せる時点を判断します。新しい保存予定があることと、新しい復旧可能なデータがあることは別です。

単純な学習モデルとして、毎正時にその瞬間の状態を保存し、保存が即座に成功し、ほかの更新記録はないとします。10時のデータが正常なら、10時10分の障害では10分前の状態まで戻せます。しかし10時50分の障害なら50分前の状態です。「一時間ごとに保存しているからRPO10分を守れる」とは言えません。

このモデルでRPO15分を目標にするなら、少なくとも障害の15分前以降を再現できる仕組みが必要です。保存間隔を短くすることは一つの方法ですが、処理の遅れや失敗を考慮せず、設定値だけを達成実績として扱わないようにします。試験では「すべて正常に完了する」などの前提があれば、その条件に従って計算します。

更新記録を使って保存時点より後まで戻せる場合もあります。そのときは、最終バックアップの時刻だけを見て古さを決めず、指定された手順で再現できる最後の時点を使います。反対に最新の保存データが破損していれば、より古い正常な時点へ戻すことになり、許容するデータ損失期間を超える可能性があります。

RTOにも別の条件が関係します。復旧に必要なデータを選ぶ時間、復旧先の準備、データの復元、接続先の切替、必要な操作の確認などです。データを頻繁に保存できても、復旧先を一から準備して長くかかるなら、短い停止時間の目標を満たすとは限りません。保存を速くする対策と、再開を速くする対策を分けて考えます。

例えば、保存間隔だけを60分から10分へ変更し、同じ30分の復旧作業を続ける場合を考えましょう。正常な保存が前提なら戻せるデータの古さは改善できますが、復旧作業の30分が自動的に5分へ縮まるわけではありません。逆に切替を速くしても、復旧先に届いていない更新を取り戻せるとは限りません。

AWSはディザスタリカバリの実装をテストして目標達成を検証することを案内しています。机上の手順だけでなく、必要なデータが戻るか、対象業務が再開できるか、各時間が目標に収まるかを確かめる視点が重要です。

フル・差分・増分で保存する対象や復元順序を整理したい場合は、基本情報のバックアップ方式と復元の違いを確認してください。方式は復旧の手段、RTO・RPOはその手段が満たすべき目標です。両者を同じ分類として覚えないようにします。

科目Aの時刻問題を順に解く

ここからは、科目Aの学習を想定した記事独自の例題です。既存の過去問を転載したものではありません。サービス停止から必要な業務の再開までをRTOの評価対象とし、復旧後のデータ時点から停止時刻までの差をRPOの評価対象とします。

目標はRTO90分、RPO20分です。サービスは13時20分に停止しました。13時05分までの更新を含むデータへ復旧し、14時30分に必要な業務を再開したとします。停止中の新しい受付や、別の媒体からの再入力はない条件です。この復旧結果は二つの目標を満たすでしょうか。

• RTOとRPOの目標値を別々に書き出す
• 停止時刻・業務再開時刻・データ時点を区別する
• 停止時間とデータ損失期間をそれぞれ計算する
• 各実績を対応する目標以下か比較する

まず、停止時間は14時30分−13時20分＝70分です。RTO90分に対して70分なので、停止時間の目標を満たします。次に、データ損失期間は13時20分−13時05分＝15分です。RPO20分に対して15分なので、データの時点についても目標を満たします。

選択肢に85分という値があれば、どの差なのかを見直してください。13時05分から14時30分までは85分ですが、データ損失期間と停止時間を足した長さです。この例で求めるRTOの達成実績でも、RPOの達成実績でもありません。数字が合っていても、対象区間を誤ると答えが変わります。

今度は業務再開だけが15時に遅れたとします。データ時点は13時05分のままなら、停止時間は100分、データ損失期間は15分です。RTO90分を超えますが、RPO20分は満たします。遅く再開したことを理由に、RPOまで超過したと判断しないでください。

反対に再開は14時30分のままでも、復旧できるデータが12時50分までだったなら、停止時間は70分、データ損失期間は30分です。今度はRTOを満たし、RPOを超えます。変更された条件が「再開時刻」なのか「データ時点」なのかを最初に確認すると、再計算する項目を間違えにくくなります。

時刻の引き算が苦手な場合は、1時間を60分として分にそろえて考えます。13時20分から14時までは40分、14時から14時30分までは30分で、合計70分です。13時20分と14時30分を小数の13.20、14.30として引く方法は使いません。時計の表示は十進数の小数ではないからです。

境界値と条件変更を見抜く

次は、候補の中から両方の目標を満たすものを選ぶ自作問題です。目標をRTO40分、RPO10分とし、測定範囲・復旧する業務水準は四つの候補で同一とします。表のデータ損失期間は、復旧後のデータ時点から障害時刻までの差です。

候補	実際の停止時間	データ損失期間	二つの目標との関係
A	35分	8分	両方を満たす
B	45分	5分	RTOを超える
C	25分	15分	RPOを超える
D	40分	10分	両方とも境界値で満たす

答えはAとDです。最大許容値として「40分以内」「10分以内」と指定されているので、同じ値まで含みます。Dを落としてしまったら、「以内」と「未満」の読み方を見直しましょう。問題文が「40分未満」と指定した場合には判断が変わるため、境界を常に同じ扱いにしないことも必要です。

Bはデータを新しく戻せていますが、停止時間が5分長いので、両方の条件は満たしません。Cは停止が短くても、許容する10分を超えて15分前のデータまでしか戻せません。短い数字が一つある候補を選ぶのではなく、要求が二つあるなら二つの不等式でチェックします。

数値が書かれない用語問題でも、同じ読み方が使えます。「災害後、一定時間以内に注文受付を再開する」は復旧の早さです。「障害直前の確定済み注文を失わない」はデータの時点です。「閲覧機能だけ先に再開する」は機能や水準です。目標の名前を探す前に、文章の対象へ注目してください。

もう一つ注意したいのは、業務の停止後に紙などで受付を続ける場合です。再入力やデータの照合を含めて何を復旧完了とするかで、評価の対象が変わる可能性があります。その条件が書かれていない例題へ、勝手に紙の控えから復元できる前提を足すのは避けましょう。与えられた情報だけで判断するのが基本です。

復旧先へ切り替える仕組みが示されていても、「切替があるからRTO0」「複製があるからRPO0」と名前だけで結論を出さないでください。試験では切替に要する時間や更新の遅れが与えられることがあります。構成名より、その条件で何分止まり、どこまで戻せるかを見ます。

復習では、間違えた選択肢について「停止時間が何分超えた」「戻るデータが何分古すぎた」と一文で説明してみてください。略語を取り違えたのか、時刻差を誤ったのか、境界値を落としたのかが分かります。同じ問題を繰り返すときも、答えの記号だけでなく理由を再現できるかを確かめます。

基本情報のRTOとRPOの要点まとめ

基本情報のRTOとRPOは、障害発生時刻を基準にして整理すると区別できます。RTOは必要なサービスを再開するまでの許容時間、RPOは戻すデータの時点に関する目標です。両方が時間の単位でも、停止とデータ損失という別の対象を評価しています。

問題を解くときは、目標値、停止時刻、業務再開時刻、復旧するデータの時点を先に書き分けましょう。停止から再開までの差をRTOと比較し、データ時点から停止までの差をRPOと比較します。実際の結果を目標値と混ぜず、片方の達成だけで両方を満たしたと判断しないことが大切です。

RPO0はデータ損失を許容しない目標であり、停止ゼロの意味ではありません。保存の頻度や仕組みの名前だけで達成を保証せず、戻せるデータと業務再開までの工程を確認します。次の一歩として、時刻の例を自分で一つ作り、再開時刻だけを変える場合と、データ時点だけを変える場合の答えを比べてみてください。

ほかの科目A・科目Bの問題にも取り組むなら、基本情報の過去問アプリで無料演習できます。問題文の条件と選択肢の判断理由を説明し、試験全体の理解を確かめてみましょう。