システム障害や災害が発生したとき、「どれくらいの時間でシステムを復旧できるか」「どこまでデータを復元できるか」は、ビジネスの継続性に直結する重要な問題です。RTO、RPO、DRという3つの指標を理解することで、適切な災害復旧計画を立てることができます。
この記事では、インフラエンジニアやシステム担当者が押さえておくべきRTO（目標復旧時間）、RPO（目標復旧時点）、DR（災害復旧）の基本を、実例を交えて分かりやすく解説します。
RTO、RPO、DRとは？基本の理解
まず、3つの用語の定義を整理しましょう。
RTO（Recovery Time Objective）：目標復旧時間
災害やシステム障害が発生してから、どれくらいの時間でサービスを復旧させるかの目標値です。「システムが停止していい時間」とも言えます。
RPO（Recovery Point Objective）：目標復旧時点
災害発生時に、どの時点までのデータを復元できるかの目標値です。「どれくらいのデータ損失を許容するか」を示します。
DR（Disaster Recovery）：災害復旧
災害や障害からシステムを復旧させるための計画・戦略・手順の総称です。RTO/RPOを達成するための具体的な仕組みがDR戦略になります。
RTO（Recovery Time Objective）：目標復旧時間
RTOは「システムダウンからサービス再開までの許容時間」を表します。
RTOの具体例
- RTO = 1時間：金融取引システム、ECサイトなど、停止による損失が大きいシステム
- RTO = 24時間：社内業務システム、CRMなど、1日程度の停止は許容できるシステム
- RTO = 1週間：アーカイブシステム、レポート生成など、緊急性の低いシステム
RTOが短いほど、高度なDR対策（冗長化、リアルタイムレプリケーション）が必要になり、コストも増加します。
RPO（Recovery Point Objective）：目標復旧時点
RPOは「どこまで過去のデータを復元できれば良いか」を表します。
RPOの具体例
- RPO = 0分（ゼロ）：データ損失が許されない。リアルタイム同期が必要
- RPO = 1時間：1時間以内のデータ損失は許容。1時間ごとのバックアップ
- RPO = 24時間：1日分のデータ損失は許容。日次バックアップ
RPOとバックアップ頻度の関係
RPOを達成するには、RPO以下の間隔でバックアップを取得する必要があります。
- RPO = 1時間 → 1時間ごとにバックアップ
- RPO = 4時間 → 4時間ごとにバックアップ
- RPO = 24時間 → 1日1回バックアップ
RPOが短いほど、バックアップ頻度が高く、ストレージコストも増加します。
RTO vs RPO：違いを理解する
RTOとRPOは混同されやすいですが、全く異なる指標です。
RTO：復旧にかかる時間（Time）
障害発生 → サービス復旧までの時間
RPO：復旧できるデータの時点（Point）
どの時点のデータまで戻せるか
実例で理解する
午前10時にシステム障害が発生したケース：
- RTO = 2時間：正午12時までにシステムを復旧
- RPO = 1時間：午前9時時点のデータまで復元
この場合、午前9時〜10時の1時間分のデータは失われることになります。
DR（Disaster Recovery）：災害復旧戦略
DR戦略には、コストとRTO/RPOのバランスに応じて、いくつかのパターンがあります。
DR戦略の4つのパターン
1. バックアップ/リストア
- RTO：数時間〜数日
- RPO：数時間〜1日
- コスト：最も安価
- 特徴：定期的にバックアップを取得し、障害時にリストア
2. パイロットライト
- RTO：数時間
- RPO：数分〜数時間
- コスト：中程度
- 特徴：最小限のコア環境を常時稼働し、障害時にスケールアップ
3. ウォームスタンバイ
- RTO：数分〜数時間
- RPO：数秒〜数分
- コスト：やや高額
- 特徴：縮小版の本番環境を常時稼働、障害時に即座に切り替え
4. ホットスタンバイ/マルチサイト
- RTO：ほぼ0（数秒〜数分）
- RPO：ほぼ0（リアルタイム同期）
- コスト：最も高額
- 特徴：完全な本番環境を複数拠点で稼働、自動フェイルオーバー
RTO/RPOに基づくDR戦略の選び方
ビジネス要件に応じて、適切なDR戦略を選択します。
業種別の目標値例
金融・決済システム：
- RTO: 数分〜1時間
- RPO: ほぼ0（データ損失不可）
- 推奨DR: ホットスタンバイ/マルチサイト
ECサイト・Webサービス：
- RTO: 1〜4時間
- RPO: 15分〜1時間
- 推奨DR: ウォームスタンバイ
社内業務システム：
- RTO: 4〜24時間
- RPO: 1〜24時間
- 推奨DR: パイロットライト、バックアップ/リストア
クラウドでのDR実装例
主要クラウドプラットフォームでは、DR実装を支援するサービスが提供されています。
AWS での主要DR サービス
- AWS Backup：自動バックアップ管理
- Amazon S3 Cross-Region Replication：リージョン間レプリケーション
- AWS Elastic Disaster Recovery：アプリケーション復旧の自動化
- Route 53 Health Check & Failover：DNSフェイルオーバー
Azure での主要DR サービス
- Azure Site Recovery：VM・アプリケーションの災害復旧
- Azure Backup：統合バックアップ管理
- Geo-Redundant Storage (GRS)：データの地理的冗長化
- Traffic Manager：DNS ベースの負荷分散とフェイルオーバー
まとめ：適切なRTO/RPO設定のポイント
RTO、RPO、DRを正しく理解し、ビジネス要件に合った設定をすることが重要です。
✅ 押さえるべきポイント：
- RTO：復旧にかかる時間。短いほど高コスト
- RPO：復元できるデータの時点。短いほど高頻度バックアップが必要
- DR：RTO/RPOを達成するための具体的な戦略・仕組み
- コストとビジネス影響のバランスで最適な値を設定
- 全システムで同じRTO/RPOは不要。重要度に応じて差をつける
災害は「いつか起こるかもしれない」ではなく、「いつか必ず起こる」前提で対策を講じることが、事業継続性を守る鍵になります。自社のシステムに適切なRTO/RPOを設定し、それを実現できるDR戦略を構築しましょう。
インフラ・システム管理をさらに強化する関連記事
RTO/RPO/DRの理解を深めたら、開発効率化ツールやシステム管理ツールも活用して、より堅牢なインフラ環境を構築しましょう：
開発効率化・コーディング支援
- opencode – ターミナル向けAIコーディングエージェント！複数モデル対応で柔軟な開発支援を実現 – ターミナルから直接AIを活用してインフラコード作成を効率化
- Qoder – AIが完全理解するソフトウェア開発向け次世代IDE – プロジェクト全体を理解するAI搭載IDEで開発体験を革新
- Byterover – AI開発者向け自己改善型コーディング知識管理プラットフォーム – インフラ構築のベストプラクティスを蓄積してチーム全体で共有
AI開発・システム構築
- CREAO – AIを活用したカスタムアプリ開発プラットフォーム – 自然言語でシステム管理ツールを構築して運用を効率化
- Cipher by Byterover – AIコーディング支援のための共有メモリー管理プラットフォーム – インフラコードの履歴を自動記録してプロジェクト間で知識共有
- DeepSeek-V3.1 – ハイブリッド思考型AIモデルによる次世代エージェント基盤 – 複雑なインフラ設計をAIでサポート
RTO、RPO、DR よくある質問
❓ RTOとRPOはどちらを優先すべきですか？
どちらも重要ですが、ビジネス影響度によって優先度が変わります。ECサイトなど「停止時間による売上損失」が大きい場合はRTOを優先し、金融システムなど「データ損失が許されない」場合はRPOを優先します。理想的には両方を短く設定しますが、コストとのバランスで現実的な値を決める必要があります。システムの重要度に応じて、RTO/RPOを段階的に設定することも有効です。
❓ RPO = 0（ゼロ）は現実的に可能ですか？
技術的には可能です。リアルタイムレプリケーション（同期レプリケーション）を使用すれば、データ損失ゼロを実現できます。ただし、コストは非常に高額になり、ネットワーク遅延やパフォーマンスへの影響も考慮する必要があります。金融取引システムなど、データ損失が絶対に許されないミッションクリティカルなシステムでのみ採用されるのが一般的です。多くの場合、RPO = 5分や15分など、現実的な値が設定されます。
❓ DRとBCP（事業継続計画）の違いは何ですか？
DRはIT システムの復旧に焦点を当てた技術的な対策です。一方、BCP（Business Continuity Plan）は、災害時に事業全体をどう継続するかの包括的な計画で、人員配置、代替施設、サプライチェーン、顧客対応なども含みます。DRはBCPの一部であり、「ITシステムの災害復旧」という技術的側面を担当します。BCP策定時には、IT以外の要素も含めた総合的な事業継続戦略が必要です。
❓ クラウドを使えば自動的にDRは実現できますか？
いいえ、クラウドを使うだけでは自動的にDRは実現しません。クラウドプロバイダーは「DR実現のための機能やサービス」を提供しますが、実際のDR戦略設計、RTO/RPOの設定、レプリケーション構成、フェイルオーバー手順の構築は利用者側の責任です。AWS BackupやAzure Site Recoveryなどのサービスを活用し、自社のRTO/RPO要件に合わせた設計と定期的なDRテストの実施が必要です。
