RTO・RPOとは？違いや決め方、バックアップ・復旧との関係を解説
システム障害や災害などに備えて復旧要件を整理する際に、押さえておきたい指標がRTOとRPOです。RTOは「いつまでに復旧するか」、RPOは「どの時点のデータまで復旧するか」を示します。
バックアップを取得していても、必要な時間内にシステムや業務を復旧できるとは限りません。事業への影響や許容できるデータ損失などを踏まえてRTO・RPOを設定し、その目標を実現できる復旧体制を整えることが大切です。
この記事では、RTOとRPOの意味や違いをはじめ、自社に適したRTO・RPOを決める手順、設定した目標を実現できるか確認する方法を解説します。あわせて、BCP・DR・バックアップとの関係についても紹介します。
目次[非表示]
RTO・RPOとは
RTOは「いつまでにシステムや業務を復旧するか」、RPOは「どの時点のデータまで復旧するか」を示す指標です。RTOは復旧までに許容できる時間、RPOは許容できるデータ損失の範囲を考える際の目安となります。
これらはBCP（Business Continuity Plan：事業継続計画）やDR（Disaster Recovery：災害復旧）において、システムや業務をどのような状態まで復旧させる必要があるのかを整理する際の基準となります。
RTO（目標復旧時間）
RTOは「Recovery Time Objective」の略で、日本語では「目標復旧時間」と呼ばれます。
障害や災害などが発生してから、業務やシステムを復旧させるまでの目標時間です。例えば「RTO＝4時間」と設定している場合、15時にシステム障害が発生したとすると、19時までにシステムを復旧し、業務を再開できる状態にすることを目標とします。
RPO（目標復旧時点）
RPOは「Recovery Point Objective」の略で、日本語では「目標復旧時点」と呼ばれます。
障害や災害などが発生した際に、発生時点からどの程度前までのデータを復旧できればよいかを示す目標です。言い換えると、どの程度のデータ損失まで許容できるかを表します。
例えば「RPO＝4時間」と設定している場合、15時にシステム障害が発生したとすると、11時時点の状態までデータを復旧できることを目標とします。この場合、障害発生前の最大4時間分のデータが失われる可能性を許容することになります。
RTOとRPOの違い
RTOとRPOは、どちらも復旧に関する目標ですが、示している内容が異なります。
RTOは、障害などが発生してから「どのくらいの時間でシステムや業務を復旧するか」を示します。一方、RPOは、障害発生時点から遡って「どの時点のデータまで復旧するか」を示します。
▼RTOとRPOの比較表
項目 | RTO（目標復旧時間） | RPO（目標復旧時点） |
意味 | どのくらいの時間でシステム・業務を復旧するか | 過去のどの時点のデータまで復旧するか |
主な対象 | システムや業務の停止時間 | データ損失の許容範囲 |
時間軸 | 障害発生から復旧まで | 障害発生時点から過去へ遡る |
検討時の主な観点 | 業務停止をどの程度許容できるか | どの程度のデータ損失を許容できるか |
RTOとRPOを設定することで、障害発生時にどの程度の時間とデータ損失の範囲で復旧する必要があるのかを具体化できます。その要件を基準として、バックアップの取得頻度や保存方法、復旧方法、必要なシステム構成や運用体制などを検討しやすくなります。
そのため、RTOとRPOはどちらか一方だけを決めるのではなく、業務停止による影響とデータ損失による影響の両方を確認し、自社に必要な復旧要件として整理することが大切です。
RTO・RPOを実現するために確認したいこと
RTO・RPOは、障害発生時に「どの程度の時間で復旧するか」「どの時点までのデータを復旧するか」を示す目標です。ただし、目標値を設定するだけで、そのとおりに復旧できるわけではありません。
設定したRTO・RPOを実現するには、目標に応じた復旧手段や運用体制を整えておく必要があります。バックアップもその一つであり、取得しているだけでなく、必要な時点のデータが残っているか、想定した時間内に復元できるか、業務再開までの手順を実行できるかまで確認しておくことがポイントです。
ここでは、RTO・RPOを実現するために確認したい3つの点を紹介します。
必要な時点のデータが残っているか
RPOを満たすためには、障害が発生した際に、必要な時点のデータまで戻せる状態になっている必要があります。
例えば、RPOを4時間と設定していても、バックアップを1日1回しか取得していない場合、障害が発生したタイミングによっては、障害発生時点から4時間以内のデータが残っていない可能性があります。
このように、バックアップを取得していても、その取得間隔によっては設定したRPOに対応する時点までデータを復旧できない場合があります。
想定した時間内に復元できるか
バックアップからデータを復元する際は、データの読み出しや転送、リストアなどに時間がかかります。
復元にかかる時間は、データ量やネットワーク環境、バックアップの保存場所、システム構成などによって異なります。そのため、必要なデータがバックアップに残っていても、復元に時間がかかれば、設定したRTO内に復旧できない可能性があります。
RTOは業務やシステムを復旧するまでの目標時間であるため、バックアップからの復元に要する時間もRTOに影響します。
業務再開までの復旧手順を実行できるか
システムの復旧では、バックアップからデータを元に戻しただけで、すぐに業務を再開できるとは限りません。
環境によっては、OSやアプリケーションの設定、ネットワークの確認、復旧後の動作確認などが必要になる場合があります。また、復旧作業の担当者や手順が明確になっていなければ、作業の開始や判断に時間がかかる可能性もあります。
そのため、RTOにはデータの復元時間だけでなく、障害発生からシステムを復旧し、業務を再開するまでに必要な一連の作業も影響します。
自社のRTO・RPOを決めるときの進め方
RTO・RPOに一律の基準があるわけではなく、必要な水準は企業や業務、対象となるシステムによって異なります。
そのため、業界などの数値をそのまま当てはめるのではなく、業務停止による影響やデータ損失の影響、復旧の優先順位、実現可能性や運用負荷・コストなどを踏まえて、自社に必要な水準を決めることが大切です。
STEP1｜業務停止時の影響を把握する
まずは、対象となるシステムが停止した場合に、どのような影響が生じるかを整理します。
例えば、売上への影響、顧客対応の停止、取引先への影響、社内業務の停滞などが考えられます。また、システムを利用できない場合に、手作業などで一時的に業務を継続できるかも確認します。
同じ種類のシステムであっても、企業の業務内容や代替手段の有無によって、許容できる停止時間は異なります。「このシステムがどの程度停止すると業務への影響が大きくなるのか」を整理することで、RTOを検討しやすくなります。
STEP2｜データの更新頻度と許容できる損失を確認する
次に、システムで扱うデータがどの程度の頻度で更新され、どこまでのデータ損失を許容できるかを確認します。
頻繁に更新されるデータや、失われた場合の影響が大きいデータでは、許容できるデータ損失を小さく設定することが考えられます。一方、更新頻度が低いデータや、別の方法で再作成できるデータなどは、許容できる損失が異なる場合があります。
データが失われた場合の影響を整理したうえで、「どの時点まで戻せれば業務を継続できるか」を検討することが、RPOを決めるポイントです。
STEP3｜復旧の優先順位をつける
複数のシステムを運用している場合、すべてを同時に復旧できるとは限りません。業務への影響度やシステム間の依存関係などを踏まえ、どのシステムから復旧する必要があるのか、優先順位を整理します。
優先順位を明確にすることで、早期の復旧が必要なシステムと、一定期間の停止を許容できるシステムに分けて考えられます。
すべてのシステムに同じRTO・RPOを設定するのではなく、業務への影響や重要度に応じて、それぞれに必要な復旧水準を整理することがポイントです。
STEP4｜実現可能性や運用負荷・コストを踏まえて調整する
最後に、検討したRTO・RPOを実現できるシステム構成や運用体制を整えられるか、必要なコストを確保できるかを確認します。
RTOを短くしたり、RPOを短くしてデータ損失を抑えたりするほど、システム構成や運用体制に求められる水準も高くなり、導入・運用コストや管理負荷が増える場合があります。そのため、RTO・RPOは短ければ短いほどよいわけではありません。
業務停止による影響やデータの重要度に加えて、技術的な実現可能性、運用体制、管理負荷、コストなどを踏まえ、業務・システムごとに必要な水準を見極めることが大切です。
検討した目標と実現可能な水準に差がある場合は、RTO・RPOを調整したり、システム停止中に業務を継続するための代替手段を検討したりしながら、現実的な復旧要件を整理します。
RTO・RPOとBCP・DR・バックアップの関係
RTO・RPOを検討する際には、BCP、DR、バックアップとの関係を整理しておくと、復旧対策の位置づけを把握しやすくなります。
項目 | 役割・位置づけ |
BCP | 災害や事故などが発生した際に、重要な事業を継続・復旧するための全体的な方針や計画 |
RTO・RPO | 「いつまでに」「どの時点の状態まで」復旧するかを示す復旧目標 |
DR | RTO・RPOなどの復旧目標を踏まえ、ITシステムやデータを復旧するための計画・体制 |
バックアップ | データを復旧するために利用する手段の一つ |
BCPで事業継続・復旧の全体的な方針を定め、そのなかでRTO・RPOによって復旧目標を具体化します。DRでは、その目標を踏まえてITシステムの復旧方法や体制を検討し、バックアップはデータを復旧するための手段の一つとして位置づけられます。
出典：内閣府防災情報のページ『事業継続 知る・計画する』
決めたRTO・RPOを実現できるか復旧テストで確認する
RTO・RPOを設定した後は、実際の復旧作業を想定したテストを行い、設定した目標を達成できるか確認します。
復旧テストでは、バックアップからデータを復元するだけでなく、業務を再開するまでの一連の作業を実施し、主に次の点を確認します。
● RTOを満たせたか：障害が発生した想定時刻から、システムを復旧して業務を再開するまでにどの程度の時間がかかったか
● RPOを満たせたか：設定したRPOで求める時点までデータを復元できたか
● 復旧手順や担当体制に問題がないか：担当者が想定した手順で作業を進められたか、連絡や判断、エスカレーションなどに不備がなかったか
テスト結果と設定したRTO・RPOを照らし合わせ、目標を達成できなかった場合は、復旧手順や担当体制、運用方法などを必要に応じて見直します。
まとめ
RTOは「いつまでにシステムや業務を復旧するか」、RPOは「どの時点のデータまで復旧するか」を示す指標です。必要なRTO・RPOは、業務停止による影響やデータの重要度、実現可能性、運用負荷・コストなどを踏まえ、業務・システムごとに設定します。
設定後は、復旧テストを通じて実際にその目標を達成できる復旧体制になっているかを確認することが大切です。必要に応じてバックアップの保存方法や復旧方法を見直します。
ランサムウェアなども想定したバックアップ設計については、次の記事で詳しく解説します。
