RTOとRPOとの違いとは？災害復旧計画で重要な2つの指標を比較

システム障害や自然災害、サイバー攻撃、ランサムウェア被害などへの備えを検討する際、「RTO」と「RPO」という言葉がよく登場します。どちらも事業継続計画であるBCPや、災害復旧計画であるDRにおいて非常に重要な指標です。しかし、両者は似た文脈で使われるため、意味を混同されやすい言葉でもあります。RTOとRPOを正しく理解していないと、復旧計画やバックアップ戦略を適切に設計できず、障害発生時に想定以上の業務停止やデータ損失が発生する可能性があります。

RTOは、システムやサービスをどれだけ早く復旧させる必要があるかを示す指標です。つまり、「いつまでに業務やサービスを再開するか」を定義します。一方、RPOは、どの時点までのデータを復旧できればよいかを示す指標です。つまり、「どこまでのデータ損失を許容するか」を定義します。RTOは復旧時間に関する指標であり、RPOはデータ損失量に関する指標です。

たとえば、ECサイトで障害が発生した場合、RTOが1時間であれば、1時間以内にサイトを再開することを目指します。一方でRPOが15分であれば、障害発生時に失われるデータを最大15分以内に抑えることを目指します。このように、RTOとRPOはそれぞれ異なる観点から復旧計画を支える指標です。本記事では、RTOとRPOの違い、それぞれの役割、具体例、BCPやDRとの関係、設定時の考慮事項、最適化のポイントについて詳しく解説します。

1. RTOとRPOとの違い

RTOとRPOの最大の違いは、RTOが「復旧までにかかる時間」を示すのに対し、RPOは「失っても許容できるデータ量」を示す点です。どちらも時間で表現されることが多いため混同されやすいですが、対象としているものが異なります。RTOはサービス停止時間を管理するための指標であり、RPOはデータ保護レベルを管理するための指標です。

RTOとRPOの主な比較

RTOを短くするには、冗長化構成、フェイルオーバー、自動復旧、マルチリージョン構成、監視体制の強化などが重要になります。一方で、RPOを短くするには、バックアップ頻度の向上、レプリケーション、リアルタイム同期、ログバックアップ、データ保護設計が重要になります。つまり、RTOとRPOはどちらも復旧計画に関係しますが、必要となる対策や設計の重点が異なります。

また、RTOとRPOはどちらか一方だけを設定すればよいものではありません。システムを早く復旧できても、重要なデータが大きく失われていれば業務を正常に再開できません。逆に、データがほぼ失われていなくても、サービス復旧に長時間かかれば顧客や業務に大きな影響が出ます。そのため、実効性のある災害復旧計画を作るには、RTOとRPOをセットで設計することが重要です。

2. RTOとは？

RTOとは、Recovery Time Objectiveの略で、日本語では目標復旧時間と呼ばれます。障害や災害が発生した際に、システムやサービスをどれくらいの時間以内に復旧する必要があるかを示す指標です。RTOは、業務停止時間をどこまで許容できるかを判断するために使われます。

2.1 目標復旧時間

目標復旧時間とは、障害発生後にシステムやサービスを復旧するまでの目標時間です。たとえば、RTOが2時間であれば、障害や災害が発生してから2時間以内に業務やサービスを再開することを目指します。RTOは、復旧作業のスピードを測る基準であり、障害対応計画や運用体制を設計する際の重要な前提になります。

RTOを短く設定するほど、より高度な可用性設計が必要になります。単純なバックアップから手動で復元する方式では、数分から数十分以内の復旧は難しい場合があります。そのため、短いRTOを実現するには、冗長構成、自動フェイルオーバー、待機系システム、DRサイト、クラウドの自動復旧機能などを組み合わせる必要があります。

2.2 サービス停止許容時間

RTOは、サービス停止許容時間とも深く関係します。サービス停止許容時間とは、システムが停止しても業務や顧客への影響を許容できる最大時間のことです。たとえば、オンライン決済や金融取引のような重要サービスでは、停止時間が数分でも大きな問題になる場合があります。一方で、社内ポータルのようなシステムでは、数時間から1日程度の停止が許容される場合もあります。

サービス停止許容時間を整理する際には、業務への影響、顧客への影響、売上損失、法令や契約上の制約を確認する必要があります。すべてのシステムに同じRTOを設定すると、過剰投資や運用負荷の増加につながる可能性があります。RTOは、システムごとの重要度に応じて設定することが重要です。

2.3 業務継続との関係

RTOは、業務継続性を確保するための重要な指標です。障害発生時にどの業務を優先して復旧すべきか、どのシステムに高い可用性を持たせるべきか、どの程度の運用体制を準備すべきかは、RTOによって大きく変わります。重要業務のRTOを明確にしておけば、緊急時にも復旧優先順位を判断しやすくなります。

業務継続計画では、すべての業務を同時に復旧することは現実的ではありません。そのため、売上や顧客対応に直結する業務、法令上停止できない業務、社内業務の中核となるシステムを優先してRTOを設定します。RTOは、BCPやDR計画の中で、業務再開の目標を具体化する役割を持ちます。

3. RPOとは？

RPOとは、Recovery Point Objectiveの略で、日本語では目標復旧時点と呼ばれます。障害や災害が発生した際に、どの時点までのデータを復旧できればよいかを示す指標です。RPOは、許容できるデータ損失量を時間で表すものであり、バックアップ戦略やデータ保護設計に大きく関係します。

3.1 目標復旧時点

目標復旧時点とは、障害発生時に復旧するデータの基準となる時点です。たとえば、RPOが1時間であれば、障害発生時に最大1時間前までのデータ損失を許容するという意味になります。RPOが15分であれば、復旧時点を障害発生から15分以内の範囲に抑える必要があります。

RPOを短く設定するほど、障害発生直前に近いデータを復旧できる必要があります。そのためには、日次バックアップだけでは不十分な場合があります。ログバックアップ、スナップショット、レプリケーション、リアルタイム同期などを活用することで、復旧可能な時点をより新しく保つことができます。

3.2 許容データ損失量

RPOは、許容データ損失量を定義する指標です。データ損失量といっても、実際には時間で表現されることが一般的です。たとえば、RPOが24時間であれば、最大24時間分のデータ損失を許容するという意味になります。RPOが0〜5分であれば、データ損失をほぼゼロに近づける必要があります。

許容データ損失量は、データの重要度によって変わります。オンライン決済、金融取引、注文情報、在庫情報、医療記録などは、少しの損失でも重大な問題になる可能性があります。一方で、社内掲示板や一部の分析用データであれば、数時間から1日程度のデータ損失が許容される場合もあります。RPOは、データ重要度に応じて設計することが大切です。

3.3 バックアップとの関係

RPOは、バックアップ戦略と非常に深く関係します。バックアップ頻度が低ければ、障害発生時に失われるデータ量は大きくなります。たとえば、1日1回だけバックアップを取得している場合、障害のタイミングによっては最大1日分のデータが失われる可能性があります。1時間ごとにバックアップを取得すれば、データ損失は最大1時間程度に抑えられます。

ただし、バックアップ頻度を高めればよいという単純な話ではありません。頻繁なバックアップには、ストレージコスト、処理負荷、ネットワーク負荷、運用負荷が伴います。そのため、重要なデータには短いRPOを設定し、重要度の低いデータには長めのRPOを設定するなど、データ保護レベルを分けて設計することが重要です。

4. RTOの具体例

RTOは、システムの種類や業務重要度によって設定値が大きく変わります。顧客向けサービスや売上に直結するシステムでは短いRTOが求められ、社内向けの補助的なシステムでは長めのRTOでも許容される場合があります。

4.1 ECサイト

ECサイトでは、システム停止が直接売上損失につながります。商品閲覧、カート投入、注文、決済、会員ログインなどの機能が利用できなくなると、顧客は購入できず、競合サイトへ移動する可能性があります。そのため、ECサイトでは比較的短いRTOが求められます。

特にセール期間やキャンペーン期間、広告配信中はアクセスが集中し、停止時の影響が大きくなります。通常時は1時間以内の復旧で許容される場合でも、繁忙期にはさらに短いRTOが必要になることがあります。ECサイトでは、売上影響と顧客体験を考慮してRTOを設定することが重要です。

4.2 金融システム

金融システムでは、取引、送金、決済、残高照会などの処理が停止すると、顧客や市場に大きな影響を与えます。金融サービスは信頼性が非常に重視されるため、RTOは短く設定される傾向があります。オンライン決済や取引システムでは、数分から数十分以内の復旧が求められる場合もあります。

金融システムのRTOを短くするには、高可用性構成、フェイルオーバー、DRサイト、リアルタイム監視、自動復旧などを組み合わせる必要があります。また、復旧時間だけでなく、復旧後のデータ整合性も重要です。金融システムでは、RTOとRPOの両方を厳密に設計する必要があります。

4.3 基幹業務システム

基幹業務システムは、受発注、在庫、会計、人事、生産管理など、企業活動の中核を支えるシステムです。基幹システムが停止すると、社内業務全体に影響が広がる可能性があります。そのため、業務内容に応じて数時間以内のRTOが設定されることがあります。

ただし、基幹業務システムでも、すべての機能を同じ時間で復旧する必要があるとは限りません。受注や出荷に関わる機能は優先度が高く、参照系やレポート系の機能は後回しにできる場合があります。RTOを機能単位や業務単位で分けることで、より現実的な復旧計画を作成できます。

RTO設定例

5. RPOの具体例

RPOも、システムの種類や扱うデータの重要度によって大きく異なります。リアルタイム性が求められるデータでは短いRPOが必要になり、更新頻度が低いデータや再作成可能なデータでは長めのRPOでも許容される場合があります。

5.1 リアルタイムデータ

リアルタイムデータとは、常に更新され、失われると業務や顧客に大きな影響を与えるデータです。オンライン決済、金融取引、在庫引当、予約情報、注文情報などが該当します。これらのデータは、数分間の損失でも重大な問題につながる可能性があります。

リアルタイムデータでは、RPOを0〜数分程度に設定することがあります。そのため、単純な定期バックアップではなく、同期レプリケーション、非同期レプリケーション、トランザクションログ、ストリーミングデータ保護などを活用します。リアルタイムデータのRPO設計では、データ損失を最小化することが重要です。

5.2 業務データ

業務データとは、日常業務で利用される受発注情報、顧客情報、在庫情報、会計情報、勤怠情報などを指します。業務データの重要度はシステムや業務内容によって異なります。基幹業務に関わるデータであれば短いRPOが必要ですが、更新頻度が低いデータでは長めのRPOでも許容される場合があります。

業務データのRPOを設定する際には、データを失った場合にどれだけ復元が難しいかを確認します。手作業で再入力できるデータなのか、他システムや紙の記録から再現できるデータなのか、失われると顧客や法令に影響するデータなのかを整理することが重要です。データ重要度に応じてRPOを分けることで、効率的なバックアップ設計が可能になります。

5.3 バックアップデータ

バックアップデータは、障害や災害発生時に復旧の基礎となるデータです。バックアップの取得頻度や保存世代によって、RPOが大きく変わります。日次バックアップであればRPOは最大24時間程度になり、時間単位や分単位のバックアップであれば、より短いRPOを実現できます。

バックアップデータでは、取得できているかだけでなく、復元できるかも重要です。バックアップファイルが破損していたり、保存先にアクセスできなかったり、復元手順が古かったりすると、障害時に想定したRPOを達成できません。RPOを守るためには、バックアップの取得、保管、復元確認までを含めて運用する必要があります。

RPO設定例

6. RTOとRPOの関係

RTOとRPOは、災害復旧計画やBCPを設計するうえで相互に関係します。RTOはサービスをいつ再開するかを決め、RPOはどの時点のデータで再開するかを決めます。両者を組み合わせることで、復旧戦略の全体像が明確になります。

6.1 復旧戦略への影響

RTOとRPOは、復旧戦略に大きな影響を与えます。RTOが短ければ、システムを早く切り替えるための冗長構成や自動復旧が必要になります。RPOが短ければ、データ損失を抑えるための高頻度バックアップやレプリケーションが必要になります。つまり、どちらの指標をどの水準に設定するかによって、必要な技術対策が変わります。

たとえば、RTOが15分、RPOが0〜5分のシステムでは、単純なバックアップ復元では対応が難しくなります。この場合、待機系環境、リアルタイム同期、フェイルオーバー、監視自動化などが必要になります。一方で、RTOが24時間、RPOが24時間のシステムであれば、日次バックアップから手動復旧する方式でも対応できる場合があります。

6.2 バランス設計

RTOとRPOは短いほど安全に見えますが、短くするほどコストや運用負荷が増えます。そのため、すべてのシステムで最短のRTOとRPOを目指すのではなく、ビジネス影響に応じてバランスを取ることが重要です。重要な顧客向けサービスには短いRTOとRPOを設定し、影響が限定的な社内システムには長めの値を設定することが現実的です。

バランス設計では、停止時間による損失と、データ損失による影響を分けて考えます。停止時間の損失が大きいシステムではRTOを短くし、データ損失の影響が大きいシステムではRPOを短くします。両方の影響が大きい場合は、より高度な可用性設計とデータ保護戦略が必要になります。

6.3 システム重要度との関係

RTOとRPOは、システム重要度に応じて設定する必要があります。オンライン決済、金融システム、基幹システム、ECサイトなどは重要度が高く、短いRTOとRPOが求められることがあります。一方で、社内ポータル、ナレッジ共有、掲示板などは、比較的長めのRTOやRPOでも許容される場合があります。

システム重要度を評価する際には、売上影響、顧客影響、業務停止、法令対応、契約上の義務、代替手段の有無を確認します。重要度に応じてRTOとRPOを分類することで、限られた予算や運用リソースを効果的に配分できます。RTOとRPOは、復旧計画を優先順位付けするための基準でもあります。

7. BCPにおける役割

BCPにおいて、RTOとRPOは重要業務をどのように継続・復旧するかを決めるための基本指標です。BCPは事業全体の継続計画であり、RTOとRPOはその中でITシステムやデータ復旧の目標を具体化する役割を持ちます。

7.1 事業継続計画

事業継続計画とは、災害、障害、感染症、サイバー攻撃などの緊急事態が発生した場合でも、重要な業務を継続または早期復旧するための計画です。BCPでは、人員、拠点、取引先、システム、データ、顧客対応などを総合的に考える必要があります。

RTOとRPOは、BCPの中でシステム復旧とデータ保護の目標を定義します。どの業務を何時間以内に再開するのか、どの時点までのデータを復旧する必要があるのかを明確にすることで、実効性のある事業継続計画を作成できます。RTOとRPOが曖昧なBCPは、実際の障害時に対応が混乱しやすくなります。

7.2 業務優先順位

BCPでは、業務優先順位を明確にすることが重要です。すべての業務やシステムを同時に復旧することは現実的ではありません。売上に直結する業務、顧客影響が大きい業務、法令や契約上停止できない業務を優先する必要があります。

RTOとRPOを設定することで、業務優先順位を具体化できます。短いRTOやRPOが必要な業務は復旧優先度が高く、長めのRTOやRPOでよい業務は後回しにできる場合があります。復旧優先順位を明確にしておけば、緊急時に限られた人員やリソースを重要業務に集中できます。

7.3 リスク管理

RTOとRPOは、リスク管理にも役立ちます。システム停止やデータ損失による影響を事前に評価し、どのリスクにどの程度の対策を行うかを判断できます。重要システムに対しては高度な冗長化やバックアップを行い、影響が小さいシステムには簡易的な対策を適用するなど、リスクに応じた設計が可能になります。

リスク管理では、技術的な障害だけでなく、自然災害、サイバー攻撃、ランサムウェア、人的ミス、外部サービス停止も考慮する必要があります。RTOとRPOを使って影響度を整理することで、事業継続性を高めながら、過剰投資を避けた現実的な対策を設計できます。

8. DRにおける役割

DRにおいて、RTOとRPOは復旧目標を決める中心的な指標です。DRは災害復旧を意味し、システムやデータを障害・災害から復旧するための計画や仕組みを指します。RTOとRPOを設定することで、DRサイトやバックアップ方式、切り替え手順を具体化できます。

8.1 災害復旧計画

災害復旧計画では、障害や災害発生時にどのシステムをどの順番で、どのデータを使って復旧するかを定義します。RTOは復旧までの時間を決め、RPOは復旧に使用するデータの時点を決めます。この二つが明確であれば、DR計画はより実践的になります。

災害復旧計画では、復旧手順だけでなく、復旧後の確認も重要です。サービスが起動していても、データが古かったり不整合があったりすれば、業務を正常に再開できません。DRでは、システム復旧とデータ復旧を一体で考える必要があります。

8.2 復旧目標設定

DRにおける復旧目標設定では、システムごとにRTOとRPOを定義します。たとえば、オンライン決済はRTO15分、RPO0〜5分、社内ポータルはRTO24時間、RPO24時間といった形で設定します。これにより、必要な対策レベルをシステムごとに分けられます。

復旧目標を設定する際には、業務部門とIT部門の連携が重要です。IT部門だけで復旧目標を決めると、実際の業務影響と合わない場合があります。業務部門が求める復旧水準と、IT部門が実現可能な技術・コストをすり合わせることで、現実的なDR計画を作成できます。

8.3 DRサイト運用

DRサイトとは、メイン環境が利用できなくなった場合に使用する代替環境です。RTOが短い場合は、すぐに切り替えられるホットスタンバイ構成が必要になることがあります。RPOが短い場合は、DRサイトへ最新に近いデータを複製しておく必要があります。

DRサイト運用では、平常時からデータ同期、監視、テスト、手順書整備を行うことが重要です。DRサイトを用意していても、実際に切り替えられなければ意味がありません。定期的なDR訓練や復旧テストを行い、RTOとRPOを満たせるか確認する必要があります。

9. 設定時の考慮事項

RTOとRPOを設定する際には、ビジネス影響、顧客への影響、コストとのバランスを考慮する必要があります。短いRTOやRPOは安全性を高めますが、その分だけコストや運用負荷が増えます。現実的な復旧計画を作るには、事業上の必要性に基づいて設定することが重要です。

9.1 ビジネス影響

ビジネス影響とは、システム停止やデータ損失が売上、業務、契約、法令対応に与える影響のことです。たとえば、ECサイトが停止すれば売上機会を失い、基幹システムが停止すれば受発注や在庫管理が滞ります。データ損失が発生すれば、顧客対応や監査にも影響する可能性があります。

RTOとRPOを設定する際には、停止時間ごとの損失やデータ損失時の影響を試算することが有効です。1時間停止した場合の売上損失、1日分のデータが失われた場合の復旧作業量、顧客問い合わせの増加などを整理します。ビジネス影響を把握することで、必要な復旧レベルを判断しやすくなります。

9.2 顧客への影響

顧客向けサービスでは、RTOとRPOは顧客体験や信頼に直結します。サービス停止が長引けば顧客は不満を感じ、データが失われれば信頼を大きく損なう可能性があります。特に決済、予約、注文、契約、医療、金融などの領域では、顧客への影響を慎重に評価する必要があります。

顧客への影響を考える際には、障害通知や代替手段も重要です。復旧までの時間を短縮することに加えて、顧客へ状況を正確に伝える、代替手続きの案内を行う、復旧後に影響範囲を説明することが求められます。RTOとRPOは技術指標であると同時に、顧客信頼を守るための指標でもあります。

9.3 コストとのバランス

RTOとRPOを短くするには、冗長化、DRサイト、レプリケーション、リアルタイム同期、24時間監視、自動復旧などが必要になります。これらにはインフラコスト、ストレージコスト、ネットワークコスト、人件費、運用負荷が伴います。そのため、必要以上に厳しいRTOやRPOを設定すると、費用対効果が悪くなる可能性があります。

コストとのバランスを取るには、システムを重要度別に分類することが有効です。最重要システムには短いRTOとRPOを設定し、重要度の低いシステムには長めの値を設定します。すべてを最高レベルにするのではなく、事業リスクに応じて対策を最適化することが、現実的な復旧計画のポイントです。

10. RTOとRPOを最適化するポイント

RTOとRPOを最適化するには、業務要件を整理し、バックアップ戦略を見直し、定期的に復旧テストを実施することが重要です。RTOとRPOは一度設定して終わりではなく、事業環境やシステム構成の変化に合わせて見直す必要があります。

10.1 業務要件を整理する

最初に行うべきことは、業務要件を整理することです。どの業務が重要なのか、どのシステムが停止すると大きな影響が出るのか、どのデータが失われると業務継続に支障が出るのかを明確にします。業務要件が整理されていなければ、RTOやRPOを適切に設定できません。

業務要件を整理する際には、業務部門、IT部門、運用部門、経営層が連携することが重要です。現場が求める復旧水準、ITが実現可能な構成、経営が許容できるコストをすり合わせることで、実効性のあるRTOとRPOを設定できます。復旧目標は、技術だけでなく業務全体を見て決める必要があります。

10.2 バックアップ戦略を見直す

RPOを最適化するには、バックアップ戦略の見直しが欠かせません。バックアップ頻度、保存場所、保存期間、復元手順、レプリケーション方式を確認し、現在のRPOを満たせるかを評価します。バックアップを取得していても、復元に時間がかかりすぎたり、データが古すぎたりすれば、実際の復旧には役立ちません。

バックアップ戦略では、RTOとの関係も考える必要があります。データが保護されていても、復元作業に長時間かかればRTOを達成できません。そのため、バックアップからの復元時間、復元後の確認手順、業務再開までの流れも含めて設計することが重要です。バックアップは、取得だけでなく復旧できることが前提です。

10.3 定期的に復旧テストを実施する

RTOとRPOは、実際にテストしなければ達成できるか分かりません。復旧手順書があっても、担当者が対応できなかったり、バックアップが破損していたり、DRサイトへの切り替えに想定以上の時間がかかったりすることがあります。定期的な復旧テストによって、計画と実態の差を確認できます。

復旧テストでは、復旧までにかかった時間と、復旧できたデータの時点を確認します。つまり、RTOとRPOの両方を検証します。テスト結果をもとに、手順書、監視設定、バックアップ頻度、レプリケーション、運用体制を改善することで、実効性の高い復旧体制を構築できます。

おわりに

RTOとRPOは、どちらも災害復旧や事業継続計画に欠かせない重要な指標ですが、それぞれ役割が異なります。RTOは「どれだけ早くシステムやサービスを復旧するか」を示し、RPOは「どれだけのデータ損失を許容するか」を示します。RTOは復旧時間の指標であり、RPOは復旧時点やデータ損失量の指標です。

両者を正しく理解することで、バックアップ戦略、DRサイト、可用性設計、レプリケーション、フェイルオーバー、自動復旧などの対策を適切に設計できます。システムを早く復旧するだけでは不十分であり、必要なデータをどの時点まで復旧できるかも重要です。RTOとRPOを組み合わせて考えることで、より実効性の高い復旧計画を作成できます。

また、RTOとRPOは短ければ短いほどよいというものではありません。短い復旧時間や少ないデータ損失を実現するには、高度なシステム構成や運用体制が必要になり、コストも増加します。そのため、ビジネス影響、顧客への影響、データ重要度、運用負荷、コストとのバランスを踏まえて設定することが重要です。

災害や障害への備えでは、RTOとRPOを設定するだけでなく、定期的な復旧テストやDR訓練を通じて実際に達成できるかを検証する必要があります。事業環境やシステム構成が変化すれば、復旧目標も見直す必要があります。RTOとRPOを継続的に管理・改善することで、障害発生時の影響を最小限に抑え、事業継続性と顧客信頼を高めることができます。