RPO・RTOの決め方｜バックアップ・DR設計4パターンと実装

RPO・RTOとは｜2つの復旧目標の違い

結論として、RPOとRTOは測っている軸が違います。RPOは時間軸を「過去に向かって」測り、RTOは「未来に向かって」測ります。障害発生時点を起点に、どちらへ伸びる線かを押さえると混同しません。

RPO（目標復旧時点）＝どこまでのデータ損失を許容するか

RPO（Recovery Point Objective）は、障害から復旧したときに戻せるデータの時点です。Google Cloudの障害復旧計画ガイドでは「重大なインシデントが原因でアプリケーションからデータが失われている状態が許容される最大時間」と定義されています。

RPO1時間なら、最大で直近1時間分のデータが失われることを事業側が受け入れている状態です。この値が、そのままバックアップ取得間隔またはレプリケーション方式の要件になります。

RTO（目標復旧時間）＝いつまでに復旧するか

RTO（Recovery Time Objective）は、障害発生からサービス再開までに許容される停止時間です。同ガイドでは「アプリケーションがオフラインである状態が許容される最大時間」とされています。

注意したいのは、RTOに含まれる範囲です。検知・判断・切り替え・動作確認までを含めるのが実務的で、「リストアコマンドの実行時間」だけをRTOと呼ぶと確実に超過します。障害に気づくまでの時間を含めるかどうかは、設計時に関係者と明示的にすり合わせてください。

SLA・MTTRとの関係

SLAは顧客との約束、RTO/RPOは社内の設計目標です。両者は近い値になりがちですが、SLAの稼働率をそのままRTOに読み替えることはできません。月間稼働率99.9%は月あたり約43分の停止を許容する計算ですが、これは「1回の障害で43分以内に戻す」という意味ではありません。

MTTR（平均復旧時間）は実績値、RTOは目標値です。訓練や障害対応の実績からMTTRを測り、RTOと乖離していないかを定期的に確認します。障害対応そのものの進め方は「障害対応の手順とポストモーテムの書き方｜一次対応から再発防止まで」で整理しています。

ミニFAQ：RPOをゼロにできますか？

同期レプリケーションを使えば理論上はゼロに近づけられます。ただしデータ破損や誤削除は正常な書き込みとして複製されるため、「レプリケーションがあるからバックアップは不要」は成り立ちません。論理障害に対するRPOは、別途ポイントインタイムリカバリで担保します。

RPO・RTOの決め方｜事業側から逆算する5ステップ

目標値は、技術的に実現できる範囲から選ぶのではなく、停止したときの損失から逆算します。順序を逆にすると「できる構成に合わせて目標を後付けした」設計になり、障害時に事業側と認識がずれます。

STEP1 守る対象を業務単位で並べる

システム名ではなく業務単位で並べます。「ECサイト」ではなく「注文受付」「決済」「在庫引当」「出荷指示」「売上集計」のように分解すると、重要度の差がはっきりします。

STEP2 停止コストを時間軸で見積もる

1時間止まったとき、4時間、24時間止まったときの損失を事業側に出してもらいます。売上機会損失だけでなく、違約金・問い合わせ対応コスト・信用低下も対象です。金額が出せない場合でも「何時間から致命的か」の線は引けます。

ヒアリングで使える質問を挙げます。

• この業務が止まると、最初に困るのは誰ですか

• 手作業で代替できますか。できるとしたら何時間まで持ちますか

• 直近1時間の入力データが消えた場合、再入力は可能ですか

• 法令や契約で定められた復旧・報告の期限はありますか

• 過去に止まったことはありますか。そのとき何時間でしたか

STEP3 候補値を置いて技術コストと突き合わせる

RPO/RTOの候補を2〜3案出し、それぞれの構成と概算費用を並べて提示します。「RTO30分なら月額はこの水準、4時間なら半分以下」という形で見せると、事業側が判断できます。ここで初めて技術側の情報を入れるのが順序として自然です。

STEP4 システム単位に落とす

全社一律の値は置きません。決済や認証はRTO分単位・RPOほぼゼロ、社内向けの分析基盤はRTO1営業日・RPO24時間、といった差をつけます。重要度の低い系まで短い目標を置くと、コストが跳ね上がります。

STEP5 合意して文書化する

決めた値は、システム台帳やArchitecture Decision Recordに残します。記載するのは数値だけでなく、前提（対象障害の範囲・RTOに含める工程）と、決めた日付・合意者です。前提が書かれていないRTOは、障害時に必ず解釈でもめます。

ミニFAQ：事業側が「止まったら困る、ゼロにして」としか言わない場合は？

STEP3の費用比較を先に見せるのが早道です。RTOを1桁短くすると常時稼働リソースが増え、費用は段階的に上がります。選択肢と金額を並べた時点で、多くの場合は現実的な線に収束します。

バックアップ設計の基本｜3-2-1と保持期間

RPOを満たす前提として、バックアップ自体が壊れない設計が要ります。レプリケーションだけでは、誤削除・データ破損・ランサムウェアに対応できません。

3-2-1ルールとイミュータブルバックアップ

3-2-1ルールは、データを3つ持ち、2種類の異なる媒体に保存し、うち1つを別の場所に置く考え方です。IPAも日常における情報セキュリティ対策でバックアップの隔離保管に触れています。

クラウドでは次のように読み替えます。

あわせて、削除・上書きを一定期間禁止するイミュータブル設定を有効にします。バックアップが本番と同じ認証情報で消せる状態だと、認証情報が漏れた時点でバックアップごと失われます。別アカウントへのコピーは、この観点でも有効です。

保持期間と世代管理の決め方

保持期間は、RPOとは別の軸で決めます。RPOは「どこまで戻せるか」、保持期間は「いつの時点まで遡れるか」です。論理障害は発見までに時間がかかるため、直近だけを持つ設計だと、気づいたときには正常な世代が残っていないという状態になります。

日次7世代・週次5世代・月次12世代のように階層を分けるのが一般的な組み方です。法令や契約で保存期間が定められている場合は、そちらが優先されます。

リストア検証をしていないバックアップは資産にならない

設計レビューで最も指摘が入るのがここです。取得ジョブの成功通知は「ファイルができた」ことしか示しません。復旧できるかは、実際に別環境へ戻して初めて分かります。

検証は自動化できます。定期的にバックアップから検証用環境を起動し、アプリケーションの起動とレコード件数の突合までを確認するジョブを組むと、RTOの実測値も同時に取れます。

DR構成4パターン｜RTO/RPOとコストの関係

AWSはクラウドにおけるディザスタリカバリの選択肢で、DR戦略を4つに整理しています。コストと複雑さが低いバックアップ中心の構成から、複数の稼働リージョンを使う構成までが並びます。

下表のRPO/RTO欄は、各クラウドの公開ドキュメントで示されている構成の位置づけと、公開されている設計例を整理した執筆時点の目安です。特定製品の保証値ではありません。実際に出る値は、データ量・レプリケーション方式・IaCの整備状況・切り替え手順の自動化度合いで大きく変わります。自分の環境の数字は、訓練で実測して置き換えてください。

バックアップ＆リストア

データとあわせて、インフラ構成・設定・アプリケーションコードも復旧先で再展開できる状態にしておく必要があります。AWSのホワイトペーパーは、IaCがないと復旧先での再構築が複雑になり、RTOを超過する可能性があると明記しています。

Terraformなどで構成をコード化しておくと、この部分のRTOが大きく縮みます。Terraformとは？IaCの仕組み・できること・フリーランス案件の単価をエンジニア視点で解説もあわせて参照してください。

パイロットライト

データのレプリケーションとコアインフラだけを常時用意し、アプリケーションサーバーは停止状態で置く構成です。必要になったときに起動してスケールアウトします。

データ層の継続レプリケーションがRPOを決めます。マネージドDBのクロスリージョンレプリカやオブジェクトストレージのレプリケーションが該当します。AWS RDSとは｜マネージドDBの基本・MySQL/PostgreSQLとの違い・案件単価をフリーランス視点で解説で、マネージドDB側の機能を整理しています。

ウォームスタンバイ

縮小版だが動作する環境を、復旧先に常時稼働させる構成です。パイロットライトとの違いは、追加操作なしでトラフィックを受けられるかどうか。パイロットライトは「起動」が要り、ウォームスタンバイは「スケールアップ」だけで済みます。

ただしオートスケールは制御系の操作にあたるため、障害時に依存しすぎると復旧の確実性が下がります。初期トラフィックを捌ける分だけ先に確保し、その後をスケールに任せる組み方が現実的です。

マルチサイト アクティブ/アクティブ

複数リージョンで同時に稼働させ、フェイルオーバーという概念をなくす構成です。最も複雑でコストが高い一方、多くの障害で復旧時間をほぼゼロに近づけられます。

書き込みの扱いが設計の山場です。1リージョンに書き込みを集約するか、最も近いリージョンへ書き込むか、パーティションキーで振り分けるかで、整合性の担保方法が変わります。

ミニFAQ：アクティブ/アクティブならバックアップは不要ですか？

不要にはなりません。AWSのホワイトペーパーも、データ破損・削除を伴う障害では復旧時間がゼロにはならず、復旧時点も障害発覚より前のどこかになると述べています。リージョン障害とデータ障害は別物として設計します。

クラウド3社のDR実装｜AWS・Google Cloud・Azure

主要3社とも、同じ考え方を自社サービスに割り当てています。名称は違っても、データ層のレプリケーション・トラフィック切り替え・構成の再展開という3要素は共通です。

表内のサービス名は執筆時点の公式ドキュメントに基づきます。クラウドのサービスは改廃があるため、設計書に落とす前に各社の公式ページで現行の位置づけを確認してください。たとえばGoogle Cloudの旧Deployment Managerは公式のサポート終了告知のとおり2026年3月31日でサポートを終了しており、Infrastructure ManagerやTerraformへの移行が案内されています。

データ層のレプリケーションでRPOが決まる

AWSのホワイトペーパーは、Aurora Global Databaseについて「セカンダリリージョンへのレプリケーション遅延は通常1秒未満」「リージョン全体の障害時でもセカンダリを1分未満で昇格できる」と記載しています。これは典型値として示された数値で、書き込み量やリージョン間の条件で変動します。設計書に引用する際は、出典とあわせて「典型値であり保証値ではない」ことを添えてください。

一方で、サービスによっては想定より長い値が示されている場合もあります。MicrosoftのAzure Backupの信頼性では、リージョン障害時にプライマリのRPOが24時間、セカンダリへの複製に最大12時間かかるため、最大36時間のデータ損失が想定されると説明されています。マネージドサービスを使っているからRPOが短いとは限りません。使う機能ごとに公式ドキュメントで確認してください。

トラフィック切り替えの落とし穴

DNSベースの切り替えは、キャッシュの影響を受けます。TTLが長いまま本番運用していると、切り替えても旧系にアクセスが残ります。分単位のRTOをDNS切り替えで実現する構成では、TTLをRTOより十分短く設定しておく必要があります。ただしTTLを短くするとDNSクエリ数と名前解決の負荷が増えるため、RTO要件とのバランスで決める値です。リージョン障害時はDNS以外の経路（エニーキャストIPやCDNのオリジンフェイルオーバー）も選択肢になります。

ヘルスチェックによる自動フェイルオーバーは慎重に扱います。誤検知で切り替わると、不要なダウンタイムとデータ損失を自分から招くことになります。AWSのホワイトペーパーも、自動フェイルオーバーは注意して使うべきで、手動起動のフェイルオーバーがよく採られると述べています。手動起動にしたうえで、起動後の手順はスクリプト化しておく構成が、確実性と速度を両立させる形になります。

IaCの整備状況がRTOを左右する

復旧先で環境を作り直す時間は、構成がコード化されているかで桁が変わります。手順書ベースの再構築は、担当者の練度に依存してRTOがぶれるのが問題です。

Azure Well-Architected Frameworkのディザスターリカバリーのためのアーキテクチャ戦略も、復旧計画の文書化と自動化を推奨しています。Kubernetes基盤であればマニフェストとクラスタ構成の両方をコード管理下に置きます（Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説）。

復旧訓練（DRテスト）の設計｜頻度と型

結論として、訓練していないDR構成は「あるつもり」の状態です。AWSもGoogle Cloudも、復旧計画を定期的にテストすることを公式に推奨しています。

訓練は3段階に分けると回しやすい

重要度の高い系ほど頻度を上げます。最低ラインとしては、リストア検証を四半期に1回、切り替え訓練を年1回。この2つが回っていない状態でRTOを宣言するのは避けたほうが安全です。

訓練で測る指標

訓練の目的は「成功した」と言うことではなく、数値を取ることです。

• 検知から復旧判断までにかかった時間

• 切り替え開始から疎通確認までの時間

• 実際に失われたデータの範囲（RPOの実測）

• 手順書どおりに進まなかった箇所の件数

• 判断に必要な情報がすぐ手に入らなかった箇所

測った値がRTO/RPOを超えていれば、目標値か構成のどちらかを見直します。訓練結果はポストモーテムと同じ形式で残すと、次回の比較がしやすくなります。意図的に障害を起こして検証する手法は「カオスエンジニアリングとは｜障害注入の手順・ツールとSREでの実践」で扱っています。

よくある失敗と対策

設計レビューや障害後の振り返りで繰り返し出てくるパターンを挙げます。

バックアップは取れていたがリストアできなかった

暗号化キーが復旧先にない、スナップショットの共有設定が別アカウントに向いていない、といった理由で止まります。対策は前述のリストア検証の自動化です。キーとバックアップを同じ場所だけに置かないのも原則になります。

バックアップごと暗号化・削除された

ランサムウェアや認証情報の漏洩で、本番とバックアップが同時にやられるケースです。イミュータブル設定、別アカウント保管、バックアップ削除権限の分離の3点で守ります。運用アカウントからバックアップを消せる状態は、設計上の欠陥として扱って構いません。

構成が手作業で、RTOを大幅に超過した

データは15分で戻ったのに、ネットワークとIAMの再構築に半日かかる、という形で顕在化します。データのRPOばかり議論してインフラのRTOを見落とすのは、設計レビューで頻出する抜けです。復旧対象には、VPC・セキュリティグループ・証明書・DNS・シークレットまで含めてください。

目標値を決めたが、誰も合意していなかった

インフラ側だけで決めたRTOは、障害時に「なぜ4時間もかかるのか」という話になります。STEP5の文書化と合意を飛ばさないことが対策です。

監視が復旧先にない

切り替えた先でメトリクスもログも見えず、復旧したかどうか判断できない状態です。監視・ログ基盤もDR対象に含めます（Datadogとは｜統合監視SaaSの特徴・Sentryとの違い・案件単価を徹底解説）。

フリーランスエンジニアがDR案件で押さえる論点

DR設計は、クラウド移行・基盤刷新・監査対応のいずれかに付随して発生することが多い領域です。単独で「DR設計」と銘打った募集より、インフラ設計・SRE・クラウド移行の案件要件に含まれる形で出てくるのが実情です。

参画前に確認したい項目を挙げます。

• 既存のRTO/RPOが文書化されているか、これから決めるのか

• 決定権を持つ事業側の担当者と直接話せるか

• 復旧訓練を実施できる停止枠を取れるか

• IaCがどこまで整備されているか（未整備なら作業範囲が大きく変わります）

• 監査・法令要件が絡むか（金融・医療系は要件が具体的に定められていることがあります）

とくに3つ目は、実務上の分かれ目になります。訓練枠を取れない現場では、設計はできても検証できず、成果が「ドキュメント納品」で終わりがちです。

単価については、首都圏中心の主要フリーランスエージェント数社が公開しているインフラ・SRE系の募集を観測ベースで見ると、クラウド設計の実務経験を持つ層向けの案件が中心価格帯を形成しています。DR設計そのものを切り出した公開案件は多くないため、インフラ設計・SRE案件の相場感で捉えるのが実態に近いです。具体的なレンジは「SREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安」「AWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説」で整理しています。

自分が今どのくらいの単価を狙えるか確認したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。インフラ領域の募集はインフラエンジニアの案件一覧から確認してください。

クラウド移行プロジェクトの文脈でDR要件が出てくるパターンは「クラウド移行案件のフリーランス単価相場・必要スキル・獲得法」が参考になります。

DR設計チェックリスト

設計レビュー前に、以下を埋められるか確認してください。埋まらない欄が、そのまま次にやることになります。

まとめ

DR設計は、事業側から逆算したRPO・RTOを決め、それを満たす最小構成を選び、訓練で実測するまでが1セットです。 構成パターンの知識だけでは設計は成立しません。

• RPOはデータ損失の許容幅でバックアップ間隔を決め、RTOは停止時間の許容幅でDR構成を決める

• 目標値は業務単位の停止コストから逆算し、システムごとに分ける。全社一律は置かない

• DR構成4パターンは、RTO/RPOを短くするほど常時稼働リソースとコストが増える

• バックアップは3-2-1に加え、イミュータブル設定と権限分離で改ざん・削除から守る

• 復旧対象はDBだけでなく、ネットワーク・IAM・証明書・シークレット・監視まで含める

• リストア検証は四半期に1回、切り替え訓練は年1回以上を最低ラインとして確保する

• 訓練で測った実測値がRTO/RPOを超えていれば、目標値か構成のどちらかを見直す

次のステップとしては、担当しているシステムで「直近のリストア検証はいつか」を確認するところから始めてください。日付が出てこなければ、そこが最初の着手点です。

参照した一次情報をまとめます。

• AWS：クラウドにおけるディザスタリカバリの選択肢

• Google Cloud：障害復旧計画ガイド

• Microsoft：ディザスターリカバリーのためのアーキテクチャ戦略

• Microsoft：Azure Backupの信頼性

• IPA：日常における情報セキュリティ対策