RTOとRPOの違い：意味・計算例・決め方

結論から： RTO（目標復旧時間）は、障害のあとどれくらいの時間まで止まっていられるか。RPO（目標復旧時点）は、直近のデータをどこまで失ってよいかを、時間で表したものです。RTOはサービスをどれだけ早く戻すか、RPOは戻したデータがどれだけ新しいかを決めます。バックアップの頻度がRPOを、復旧の方法がRTOを左右します。

バックアップは取っているのに、「どれくらいで戻す必要があるのか」「どこまでのデータ損失なら許されるのか」を書き出したことのない企業は少なくありません。実際に障害が起きて、停止している最中にようやくその数字が議論されることになります。この記事では、RTOとRPOを平易に説明し、現実的な目標の決め方と、それぞれがバックアップ・復旧の費用にどう影響するかを解説します。

正式な定義は、NISTの用語集にある2つの項目を参照しました。どちらも連邦情報システム向けのコンティンジェンシープランニングガイドであるNIST SP 800-34 Rev. 1に基づいています：Recovery Time ObjectiveとRecovery Point Objective。2026年10月28日に確認しています（確認日：2026-10-28）。以下の例の数値は説明用の架空のものであり、Brocentの実績ではありません。

RTOとRPOの違いは？

障害のあとには、2つの問いが生じます。いつ業務を再開できるのか。どれだけの作業が失われたのか。

RTOは「どれくらい止まっていられるか」に答えます。 NISTの説明では、システムの構成要素が復旧フェーズにとどまっていても、組織の任務や業務プロセスに悪影響が出ない最大の長さを指します。
RPOは「どこまでデータを失ってよいか」に答えます。 NISTの説明では、障害のあとデータを戻さなければならない時点のことです。

RPOは時間軸で考えるとわかりやすくなります。システムが15時に止まり、最後の正常なデータが12時のものであれば、3時間分の変更が失われます。RPOが1時間なら、この差は2時間オーバーしています。

RTOは、障害の発生から、利用者が再び業務できるようになるまでの長さです。障害が15時でRTOが4時間なら、19時までに利用者が使えるようになることが目標です。

2つは独立しています。データ損失はほぼ許されないが、1日は止まっていてもよい業務（夜間は止められるが、計上済みの取引は絶対に失えない会計システムなど）もあれば、数分で戻す必要があるが直近1時間分のロスは許容できる業務（毎時間ソースから再構築されるレポートサイトなど）もあります。

バックアップ頻度はRPOをどう決める？

RPOは、正常なコピーとコピーの間隔より良くすることはできません。バックアップが1日1回なら、最悪の場合ほぼ1日分の作業が失われます。

計算例：経理チームの会計サーバーが毎晩22時にバックアップされています。翌日の17時にサーバーのストレージが故障しました。

最後の正常なバックアップは、前夜22時のものです。
そのバックアップから障害まで、19時間が経過しています。
バックアップジョブが毎晩成功していても、チームは19時間分の入力を失いました。

つまり、夜間1回のバックアップが持つ実質的なRPOは最大24時間で、「バックアップがあるからゼロ」ではありません。業務側が最大1時間しか失えないと判断したなら、バックアップの間隔は1時間以下にする必要があります。そのためには、より頻繁なスナップショット、継続的なレプリケーション、アプリケーション側のログなどが必要になり、段階が上がるごとにストレージ、ライセンス、帯域のコストが増えます。

目安：バックアップ間隔 ≤ RPO。そのうえで、ジョブの失敗や遅延に備えた余裕を持たせます。毎時間に設定していても、気づかないまま6時間失敗し続ければ、実質のRPOは7時間になります。だからこそ、バックアップの計画を立てるのと同じくらい、ジョブの監視が重要なのです。

RTOを決めるものは何？

RTOは1つの作業ではなく、複数のステップの合計であり、いちばん遅いステップが意外なところにあることがよくあります。

検知： 人または監視が障害に気づく。
判断： 権限のある人が、切り替えか復元かを決め、宣言する。
復元： バックアップからデータとシステムを再構築する、またはスタンバイ環境に切り替える。
確認： 利用者を戻す前に、復旧したサービスをテストする。
切り替え： 利用者や連携先を、復旧したサービスに向ける。

多くの場合、最も時間がかかるのは復元で、データ量と転送速度に左右されます。

計算例：クラウドバックアップから2TBのデータを復元する必要があります。2TBはおよそ16,000ギガビットです。あらゆるオーバーヘッドを無視した場合：

実効1Gbpsなら、転送に約16,000秒、およそ4.4時間かかります。
実効200Mbpsなら、約80,000秒、およそ22時間かかります。

実際の復元は、圧縮、小さなファイルの多さ、整合性チェック、他のトラフィックとの競合があるため、これより遅くなります。ポイントは、200Mbpsの回線でこの規模をクラウドだけから復元する場合、4時間のRTOは不可能だということです。達成するには、より高速な回線、高速復元用のローカルコピー、復元範囲の絞り込み（重要なデータから先に戻す）、あるいはすでに稼働しているスタンバイ環境が必要になります。

システムごとにRTOとRPOを決めるには

会社全体で1つの数字を決めてはいけません。システムごとに重要度が違い、すべてを最重要として扱うと計画が高価になりすぎます。システムごとに、次の手順で進めてください。

システムと、それに依存する業務プロセスを洗い出す：給与、メール、ERP、ファイル共有、CRM、Webサイトなど。
各プロセスについて、どれくらい止まると実害（売上の損失、法的期限の超過、従業員の手待ち）が出るかを確認する。これがRTOの候補です。
直近のどれくらいの作業なら、手作業で再入力や再作成ができるかを確認する。これがRPOの候補です。
システムをいくつかの段階に分ける。たとえば「数時間以内に復旧」「1日以内」「数日以内」などとし、本当に必要なところにだけ高速復旧のコストをかける。
技術的な実現性を確認する。バックアップ間隔でRPOを満たせるか、復旧方法でRTOを満たせるか。上のスループットの計算も含めて確かめる。
コストを見積もる。目標が厳しいほど、頻繁なコピー、多くのストレージ、多くの場合スタンバイ環境が必要です。費用が高すぎるなら、目標を緩めるか、リスクを明示的に受け入れる。
合意した目標を文書にし、業務責任者の承認を得て、少なくとも年1回、またはシステム変更のたびに見直す。

6番目のステップで失敗する計画は多くあります。コストを見積もっていない目標は、目標ではなく願望です。

従業員40人の会社なら、段階分けはどうなる？

以下の数値は、進め方を示すために作った架空のものです。実際の答えは会社ごとに異なります。

第1段階：会計システムと受注システム。 RTO 4時間、RPO 1時間。失われた取引は再現しにくく、システムが止まっている間は販売も止まります。この段階には、1時間ごとのコピー、インターネット回線に依存しない復元用のローカルコピー、テスト済みの復元手順が必要です。
第2段階：ファイル共有とCRM。 RTO 1営業日、RPO 4時間。従業員はしばらくローカルのファイルで作業でき、直近の編集は作り直せます。勤務時間中は4時間ごとのスナップショットに、夜間バックアップを加えれば十分で、クラウドから復元します。
第3段階：イントラネット、アーカイブ、テスト環境。 RTO 3営業日、RPO 24時間。夜間バックアップを取り、時間のあるときに復元します。

段階分けは、まず業務上の問いから始まり、技術はその次に来ます。この会社が1時間ごとのコピーとローカルの復元ポイントに費用をかけるのは、2つのシステムだけで、すべてではありません。

RTO・RPOは、災害復旧・BCP・MTTRとどう関係する？

事業継続計画（BCP）： 混乱の中でも事業を続けるための全体計画。RTOとRPOは、その中の技術的な復旧目標です。
ディザスタリカバリ（DR）： 計画のうち技術面の部分で、システムとデータをどう戻すか。RTOとRPOを達成できるかどうかは、DRで決まります。
最大許容停止時間： NISTの用語で、事業が耐えられる最長の停止時間のこと。RTOはそれより短くなければならず、確認と切り替えの時間も残す必要があります。
MTTR： 過去の復旧に実際にかかった平均時間。RTOは決める目標、MTTRは測った結果です。実測の復旧時間が常にRTOより長いなら、その目標は現実的ではありません。測り方は、MTTR・MTBF・MTTAの解説をご覧ください。

RTOはSLAの応答時間と同じですか？

違います。これはよくある混同です。SLAの応答時間は、サポートエンジニアがチケットの対応にどれだけ早く着手するかを示します。RTOは、サービスがどれだけ早く戻らなければならないかを示します。エンジニアが15分で応答しても、大規模なシステムの復旧には数時間かかることがあります。

Brocentの公開SLA目標は、優先度別の応答時間と解決時間を示しています。緊急（P1）チケットは初動15分、解決目標は8営業時間です。各レベルの意味はP1〜P4の優先度ガイドで解説しています。これらは、個々のシステムのRTOの代わりにはなりません。復旧目標は別に確認し、それがどのようにテストされるのかも尋ねてください。

バックアップだけでなく、復旧テストが必要な理由

テストしていないバックアップは、RTOもRPOも未知数です。書面上の数字を信頼できる数字に変える唯一の方法は、実際に復元して時間を計ることです。

少なくとも次の点をテストしてください。

重要なシステムを1つ、隔離した環境に復元し、依頼を始めてからログインできるまでの時間を計る。
復元後のデータの新しさを確認し、RPOと比べる。
障害時に実際に復元を担当する人が、手元にあるはずの手順書で復元できるかを試す。
うまくいかなかったことを記録し、改善してから再度テストする。

Brocentのクラウドマネージドバックアップは、この考え方に沿って設計されています。サービスページによれば、バックアップポリシーはお客様のRTOとRPOに合わせて調整され、バックアップジョブは24×7で監視され、復旧訓練が定期的に実施されて整合性が検証されます。これらの目標をご自身の環境に合ったバックアップ設計に落とし込みたい場合は、このページに選択肢とアセスメントの案内があります。

Brocentの公開サービスレベルと価格はどこで見られる？

サポートの応答目標はSLAのページに、マネージドITサポートのプランとユーザー単価にはマネージドITサポートの公開価格と、契約上のサービス時間帯内での緊急インシデントの15分の初回応答が掲載されています。ご自身のシステムのRTOとRPOを一緒に整理したい場合は、お問い合わせください。大規模障害が実際に起きたときの運営方法は、重大インシデント管理をご覧ください。

よくある質問

RTOは何の略ですか？

RTOはRecovery Time Objective、目標復旧時間のことです。復旧フェーズにあるシステムが、事業に許容できない影響が出る前に、最大どれくらい停止していてよいかを表します。自分で決める目標で、分または時間で表します。

RPOは何の略ですか？

RPOはRecovery Point Objective、目標復旧時点のことです。障害のあと、データを戻さなければならない時点を指します。実質的には、復元するデータの許容できる最大の古さであり、RPOが1時間なら、失ってよいのは直近1時間分までです。

RTOとRPOはどちらが重要ですか？

一概にどちらとは言えず、システムによります。決済や受注のシステムは、失われた取引を再現できないため、RPOを重視するのが一般的です。顧客向けのWebサイトは、オフラインの1時間ごとに訪問者を失うため、RTOを重視することがあります。システムごとに両方を決めてください。

RTOとRPOをゼロにできますか？

理論上は可能ですが、コストが非常に高くなります。RPOをほぼゼロにするには継続的なレプリケーション、RTOをほぼゼロにするには自動で引き継ぐスタンバイが必要です。どちらもコストと複雑さが増しますし、誤削除やランサムウェアなど、スタンバイにも複製されてしまう問題は防げません。多くの企業は、段階分けの考え方を採用しています。