災害復旧（DR）計画の立て方｜RPO・RTOの決め方とバックアップ・リージョン戦略

「バックアップは毎日取っています」と答えられても、「では、データセンターごと止まったら何時間で復旧できますか？」と聞かれて言葉に詰まる方は多いのではないでしょうか。バックアップがあることと、それを使って事業を再開できることの間には、大きな距離があります。

この記事では、災害復旧（DR：Disaster Recovery）計画の核となるRPO・RTOという2つの指標の決め方、バックアップ復元からマルチサイトまで4段階のDR構成とそのコスト、クラウドのリージョン障害で実際に何が起きるか、そして復旧手順書と定期訓練の回し方を解説します。バックアップの取り方そのもの（3-2-1ルールや手順）はバックアップ3-2-1ルールとデータベースのバックアップとPITRで扱っているため、ここでは「取ったバックアップからどう事業を戻すか」に集中します。

RPOとRTOの定義｜「どこまで失ってよいか」と「いつまでに戻すか」

2つの指標は別の質問に答えている

DR計画の議論が噛み合わない原因の多くは、この2つを混同していることにあります。

• RPO（Recovery Point Objective：目標復旧時点）：障害発生時点から遡って、最大でどれだけの期間のデータ損失を許容するか。「RPO 1時間」なら、直近1時間分の更新は失われてもよいと決めたことになる。決めるのはバックアップの頻度。
• RTO（Recovery Time Objective：目標復旧時間）：障害発生から、サービスを再開するまでに許容できる時間。「RTO 4時間」なら4時間以内に使える状態に戻す。決めるのは待機系の準備度合い。

毎晩1回のバックアップならRPOは最大24時間です。それを別の環境に復元して設定を整え、DNSを切り替えるのに半日かかるなら、RTOは12時間程度になります。「毎日バックアップしているから安心」は、暗黙のうちに「1日分のデータ消失と半日の停止を受け入れている」と言っているのと同じです。それが事業として受け入れられるかどうかを、技術側の思い込みではなく事業側と合意するのがDR計画の出発点です。

事業側との合意の取り方

事業側に「RPOは何時間にしますか」と聞いても答えは返ってきません。次のように、業務の言葉で質問を組み立てます。

1. システムが止まると、どの業務が止まるか（受注、出荷、問い合わせ対応、給与計算など）。
2. その業務が止まった場合、1時間あたり・1日あたりの損失はいくらか。紙やExcelで代替できる時間はどれくらいか。
3. 失われたデータは、別の記録（メール、伝票、決済代行会社の履歴）から再入力できるか。できるなら何時間分まで現実的か。
4. 顧客や取引先に対して、いつまでに復旧の見込みを伝える必要があるか。

この回答から「受注データはRPO 15分・RTO 2時間、社内の日報システムはRPO 24時間・RTO 3日」というように、システムごとに異なる目標が決まります。全システムを同じ水準にする必要はなく、むしろ差をつけることで限られた予算を重要な部分に集中できます。会社全体の事業継続の考え方はBCP（事業継続計画）入門にまとめています。

DR構成の4段階とコスト

準備度合いに応じた4つの型

目標が決まったら、それを満たす最も安い構成を選びます。DR構成は一般に、待機側の準備度合いで4段階に分類されます。

構成	待機側に用意するもの	典型的なRTO	典型的なRPO	相対コスト
バックアップ＆リストア	バックアップデータのみ（別リージョンのストレージ）	数時間〜1日	バックアップ間隔（時間〜日）	最小（ストレージ代のみ）
パイロットライト	DBのレプリカと最小構成のネットワーク。アプリは停止状態	数十分〜数時間	分単位	小（DBレプリカ分）
ウォームスタンバイ	縮小版の本番環境を常時稼働。障害時にスケールアップ	数分〜数十分	分〜秒	中（本番の数分の1）
マルチサイト（アクティブ/アクティブ）	本番と同等の環境を複数拠点で同時稼働	ほぼゼロ	ほぼゼロ	大（本番×2以上＋同期の仕組み）

「パイロットライト」とは、ガス給湯器の種火のように、最小限の火（DBのレプリカ）だけを灯しておき、必要になったら本燃焼（アプリ起動）に移る、という比喩です。DBは復元に時間がかかる一方、アプリはコンテナやAMIから数分で起動できるため、「時間のかかるものだけ温めておく」のが費用対効果の分岐点になります。

中小規模での現実的な選択

多くの中小規模システムでは、次のような組み合わせが現実的です。

• まず全システムをバックアップ＆リストアにする：バックアップを別リージョン（または別クラウド）に複製する。S3であればクロスリージョンレプリケーション、RDSであれば自動スナップショットの別リージョンコピーで実現できる。
• 売上に直結するシステムだけパイロットライトに上げる：DBのクロスリージョンリードレプリカを用意し、アプリのイメージとインフラ定義（Terraformなど）を別リージョンでも適用できるようにしておく。
• ウォームスタンバイ以上は、停止1時間の損失が待機環境の月額を上回る場合に検討する。

# RDSの自動スナップショットを大阪リージョンへ自動コピーする設定（東京側で実行）
aws rds start-db-instance-automated-backups-replication \
  --source-db-instance-arn arn:aws:rds:ap-northeast-1:123456789012:db:prod-db \
  --backup-retention-period 7 \
  --region ap-northeast-3

# S3バケットのバージョニングとクロスリージョンレプリケーションが有効か確認
aws s3api get-bucket-replication --bucket prod-uploads

ポイントは、バックアップを本番と同じ場所に置かないことです。同じリージョン内のスナップショットは、リージョン障害やアカウント乗っ取りには無力です。

リージョン障害では実際に何が起きるか

「一部のサービスが不安定」から始まる

クラウドのリージョン規模の障害は、多くの場合「全部が一斉に落ちる」のではなく、「特定のAZの電源障害」「API呼び出しがエラーになる」「新しいインスタンスが起動できない」といった形で始まります。過去に国内リージョンで起きた大規模障害でも、冷却設備や電源の問題で特定のAZのインスタンスが停止し、影響が数時間続いたケースがありました。

ここで問題になるのは、「サーバーは生きているが、コンソールやAPIが不安定で操作できない」「AZ障害でオートスケールが新インスタンスを起動できない」といった、平時の想定と異なる状況です。AZ単位とリージョン単位の障害の違い、そして東京・大阪リージョンの使い分けはアベイラビリティゾーンとマルチリージョンで解説しています。

トラブル事例：バックアップはあったのに復旧できなかった

症状：東京リージョンの障害でDBインスタンスが応答しなくなり、大阪リージョンにコピーしていたスナップショットから復元を始めた。しかし復元したDBにアプリがつながらず、復旧に8時間を要した。

原因：（1）DBの暗号化に使っていたKMSキーが東京リージョン固有のもので、大阪でスナップショットを復元するにはキーの再設定が必要だった。（2）アプリの設定ファイルにDBのエンドポイントがハードコードされており、新しいエンドポイントへの差し替え箇所が複数あった。（3）大阪側にVPCやセキュリティグループが存在せず、手作業で作った。いずれも「一度もリストアを試していなかった」ことに起因していた。

対処：暗号化キーをマルチリージョンキーに変更し、インフラ定義をTerraformでコード化して両リージョンに適用できるようにした。DBエンドポイントはDNSのCNAMEで抽象化し、切替時はレコード変更だけで済むようにした。さらに、四半期に一度、大阪リージョンでの復元訓練を行う運用を追加した。

復旧手順書とDNS切替の設計

手順書は「深夜に初めて見る人」が実行できる粒度で

復旧手順書（ランブック）は、障害当日に責任者が不在でも実行できることが目的です。次の要素を含めてください。

1. 発動条件と判断者：誰が「DRを発動する」と決めるか。復旧に数時間かかる場合、「30分待てば復旧するかもしれない」障害でDRを発動すると、かえって損失が増えることがある。
2. 連絡先と役割：技術対応、顧客連絡、経営判断の担当者と代替者。
3. 実行コマンドと確認方法：コピー＆ペーストできる形で。「適切に設定する」といった曖昧な記述を排除する。
4. 切替後の確認項目：ログイン、主要な業務操作、メール送信、決済など、動作確認のチェックリスト。
5. 切り戻し手順：本番リージョンが復旧したときに、DR側で更新されたデータをどう戻すか。ここが最も難しく、事前に決めていないと二重更新やデータ消失が起こる。

DNS切替で利用者を待機系に向ける

アプリのURLを変えずに待機系へ誘導する手段がDNSです。平時からTTL（キャッシュの有効秒数）を短く（60〜300秒程度）しておき、障害時にレコードの向き先を変更します。Route 53を使っている場合は、ヘルスチェックと連動したフェイルオーバールーティングで自動化もできます。

# Route 53でレコードを大阪側のALBへ切り替える例（change-batch.json）
{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "app.example.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z2xxxxxxxxxxx",
        "DNSName": "dr-alb-123456.ap-northeast-3.elb.amazonaws.com",
        "EvaluateTargetHealth": true
      }
    }
  }]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1yyyyyyyyyy \
  --change-batch file://change-batch.json

TTLが1日のままだと、切り替えても利用者の一部は1日間古いサーバーに向かい続けます。「切替の前提はTTL短縮」だと覚えてください。レコードの種類とTTLの基本はドメインとDNS設定の完全ガイドを参照してください。

定期訓練でDR計画を「動くもの」に保つ

訓練しない計画は存在しないのと同じ

DR計画の有効期限は短く、インフラの変更、担当者の異動、依存サービスの追加によってすぐに陳腐化します。半年〜1年に一度、次の段階を踏んで訓練してください。

1. 机上訓練：手順書を読み合わせ、「このステップで必要な権限は誰が持っているか」「この判断は誰がするか」を確認する。所要30分〜1時間。
2. 部分訓練：バックアップを実際に別リージョンに復元し、アプリを起動して動作確認する。本番には影響させない。
3. 全体訓練：営業時間外に実際にDNSを切り替え、DR側で業務操作を行い、切り戻す。実施できれば計画の信頼度は大きく上がる。

訓練で見つかった問題は、そのままDR計画の改善項目になります。訓練後の振り返りはポストモーテムの書き方と同じ形式で記録すると、次回の訓練で「前回の問題が直っているか」を確認できます。

計測すべき2つの実測値

訓練では「実際に何時間かかったか（実測RTO）」「復元されたデータの最終更新時刻は障害想定時刻の何分前だったか（実測RPO）」を必ず記録します。目標と実測の差がDR計画の改善余地であり、事業側に「現在の実力」を正直に報告する材料にもなります。

まとめ

DR計画は、RPO（どこまでデータを失ってよいか）とRTO（いつまでに戻すか）をシステムごとに事業側と合意するところから始まります。その目標に応じて、バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトの4段階から最も安い構成を選び、バックアップは必ず別リージョンに置く。そして、暗号化キー・ネットワーク・設定値といった「復元して初めて気づく落とし穴」を、定期訓練で事前につぶしておくことが要点です。

まずは自社の主要システムについて、「今の構成での実質的なRPOとRTOは何時間か」を書き出してみてください。その数字を事業側に見せるだけで、DR計画の議論は一気に具体的になります。RPO・RTOの設定から復旧訓練の運用設計まで伴走が必要な場合は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。