DR（災害復旧）計画は、「サーバーが使えなくなったとき、どれだけのデータを失ってよく、どれだけの時間で戻すか」を先に決め、それを実現するバックアップと手順を用意しておくものです。その2つの目標値が RPO（目標復旧時点）と RTO（目標復旧時間）です。この記事では、RTO と RPO の意味を時間軸で整理したうえで、業務への影響から目標値を決める方法、目標値に合う復旧方式の選び方、実際の復旧時間の見積もり方、計画書に書く項目、訓練の進め方までを順に説明します。小規模な Web サービスや WordPress サイトを VPS やクラウドで運用している方を想定しています。
RTOとRPOを時間軸で理解する
障害が起きた時刻を基準に、前と後ろを見ると整理しやすくなります。
- RPO（Recovery Point Objective）：障害の時点から「過去に」どこまで戻ってよいか。言い換えると、失ってもよいデータの量を時間で表したもの。RPO が24時間なら、最大で1日分のデータを失う前提になる
- RTO（Recovery Time Objective）：障害の時点から「未来に」どれだけの時間でサービスを再開するか。RTO が4時間なら、4時間以内に利用者が使える状態に戻す
RPO はバックアップの頻度と保管方法で決まり、RTO は復旧の手順と準備の度合いで決まります。性質の違う2つの値なので、別々に考えるのが基本です。
もう1つ、事業継続の分野では「最大許容停止時間」という考え方があります。これを超えて止まると、取引先を失う、法的な義務を果たせないなど、取り返しのつかない影響が出る時間です。RTO は、この許容停止時間より短く設定します。
手順1：守る対象と依存関係を洗い出す
最初に、サービスを動かすのに必要なものをすべて書き出します。サーバーとデータベースだけを考えがちですが、実際の障害では周辺の要素で復旧が止まることがよくあります。
- Web サーバー、データベース、アップロードされたファイル
- DNS とドメインの登録事業者（更新切れや、管理画面にログインできない事態も含む）
- TLS 証明書、メール送信（SMTP や送信サービス）
- 決済、外部 API、CDN などの外部サービス
- サーバーやクラウドの管理画面に入るためのアカウント、二要素認証の端末
- 設定ファイル、デプロイの手順、復旧に使うスクリプト
この一覧に「それが失われたら何が止まるか」「代わりの手段はあるか」を書き添えておくと、後の工程で優先順位を付けやすくなります。
手順2：業務への影響から目標値を決める
目標値は技術の都合ではなく、止まったときの影響から決めます。これを業務影響分析（BIA）と呼びます。たとえば次のような問いを、時間の経過ごとに考えます。
- 1時間止まったら何が起きるか。半日なら、3日ならどうか
- 失ったデータは、別の手段で取り戻せるか（注文メールの控えや、書き手の手元の原稿など）
- 利用者や取引先との約束（利用規約、SLA）で決まっている条件はあるか
結果として、システムやデータの種類ごとに異なる目標値になるのが普通です。
| 対象 | RPO の例 | RTO の例 | 考え方 |
|---|---|---|---|
| ECサイトの注文データ | 15分 | 4時間 | 注文の消失は返金や信用に直結する |
| 企業サイト・ブログ | 24時間 | 1営業日 | 記事は書き手の手元にも残っていることが多い |
| アクセスログ | 1週間 | 復旧を急がない | 分析用で、止まっても業務は回る |
すべてを短くすると費用と手間が大きく増えます。「本当に短くする必要があるのはどれか」を決めることが、計画の中心になります。
手順3：目標値に合う方式を選ぶ
RPOを満たすバックアップ
RPO は「最後に、別の場所へ保管し終えたデータ」の時点で決まります。毎日3時にバックアップを取り、3時30分に別サーバーへの転送が終わる運用なら、3時20分の障害では前日の分までしか戻せません。転送が終わるまでの時間も含めて考えてください。
- 1日1回のダンプとファイルのバックアップ：RPO はおおむね24時間
- データベースのバイナリログや差分を数分おきに別の場所へ送る：RPO を分単位にできる
- レプリケーション：RPO を秒単位にできるが、誤操作や改ざんもそのまま複製される。レプリケーションはバックアップの代わりにはならない
ランサムウェアや不正アクセスでは、攻撃者がバックアップまで削除しようとします。本番とは別の認証情報で管理する保管先や、一定期間削除できない設定（オブジェクトロックなど）にしたコピーを1つ持っておくと、この事態に備えられます。
RTOを満たす復旧方式
復旧方式は、待機させておく環境の度合いで段階的に分けられます。AWS の Well-Architected フレームワークでも、おおむね次の4段階で整理されています（2026年10月現在）。
- バックアップと復元：障害が起きてから環境を作り、バックアップを戻す。費用は小さいが RTO は数時間〜1日程度になりやすい
- パイロットライト：データの複製だけを常に動かし、サーバーは障害時に起動する
- ウォームスタンバイ：縮小した構成の待機環境を常に動かしておき、障害時に拡張して切り替える
- マルチサイト（アクティブ/アクティブ）：複数の拠点で同時に稼働させる。RTO は最短だが、構成と費用が最も大きい
小規模なサイトの多くは「バックアップと復元」で十分ですが、その場合でも、環境を作り直す手順をスクリプトやドキュメントにしておくと RTO を大きく縮められます。
実際の復旧時間を見積もる
RTO を決めたら、それが本当に守れるかを積み上げで確かめます。復旧の時間は、データを戻す作業だけではありません。
- 検知：監視で障害に気づくまで
- 判断：担当者に連絡がつき、「DR を発動する」と決めるまで
- 環境の用意：サーバーの作成、ミドルウェアの設定
- データの復元：バックアップの転送と展開、データベースの読み込み
- 切り替え：DNS の変更と、その反映
- 確認：表示、ログイン、決済、メール送信などの動作確認
夜間に障害が起きて担当者が朝まで気づかなければ、それだけで数時間が過ぎます。データベースの読み込みに3時間かかるなら、RTO が2時間という目標はそもそも達成できません。DNS は、レコードの TTL が長いと切り替えの反映に時間がかかるため、切り替え予定のレコードは普段から短めの TTL にしておく方法があります。見積もりが目標を超える項目があれば、そこが改善の優先箇所です。
計画書に書くこと
計画書は、障害のときに読む人が迷わないことを目的に書きます。分厚い文書より、手順が具体的なほうが役に立ちます。
- 目的と対象範囲、各システムの RTO と RPO
- 連絡先と役割：誰が判断し、誰が作業し、誰が利用者へ知らせるか。担当者が不在のときの代わり
- DR を発動する条件：どのような状態が何分続いたら発動するか
- 障害の種類ごとの手順書：サーバー故障、データの誤削除、不正アクセス、クラウドの障害、ドメインの失効など
- 復旧に必要な情報の保管場所：管理画面の認証情報、暗号化の鍵、手順書そのもの。本番の環境が失われても参照できる場所に置く
- 利用者への告知の文面の例と、告知の手段
- 復旧後に元の環境へ戻す手順（フェイルバック）
認証情報や鍵の保管場所は、権限のある人だけが参照できるように管理してください。計画書そのものに平文で書くのは避けます。
訓練と見直し
一度も試していない計画は、ほとんどの場合そのままでは動きません。段階を分けて訓練します。
- 机上訓練：シナリオを読み上げ、手順書どおりに進められるかを話し合いながら確かめる
- 復元訓練：別の環境にバックアップを戻し、サイトが動くことと、かかった時間を記録する
- 切り替え訓練：可能であれば、実際に待機環境へ切り替えてみる
訓練で計った時間を RTO と比べ、超えていれば手順や構成を見直します。また、サーバーの移転、構成の変更、担当者の交代があったときと、少なくとも年に1回は計画書を更新してください。
まとめ
- RPO は失ってよいデータの量、RTO は再開までの時間。別々に決める
- 守る対象には、DNS、ドメイン、証明書、管理画面のアカウントなど周辺の要素も含める
- 目標値は業務への影響から決め、システムやデータごとに差を付ける
- RPO は「別の場所に保管し終えた時点」で決まる。レプリケーションはバックアップの代わりにならない
- 実際の復旧時間は検知から動作確認までの積み上げで見積もり、訓練で計って計画を更新する