クラウドのバックアップ/DR設計を失敗しない方法（RPO/RTOの決め方）

クラウドのバックアップ/DRで「失敗」とは何か

クラウドを使っているのに、障害やインシデントの後に「想定より復旧が遅い」「データが戻らない」「復旧はできたが業務が止まったまま」という事態が起きることがあります。これがバックアップ/DR設計の失敗です。多くの場合、原因はツール不足ではなく、復旧のゴール（いつまでに・どこまで戻すか）が決まっていないことにあります。

クラウドでは「スナップショットを取っているから安心」「マルチAZだから大丈夫」と思いがちですが、実際には次のような抜け穴があります。

• スナップショットはあるが、復旧手順がなく担当者が迷う（復旧に数時間〜数日）
• バックアップは取れているが、復元テストをしておらず壊れたデータが保存されていた
• RPO/RTOが曖昧で、経営側の期待（すぐ戻る）と現場の現実（半日必要）がズレる
• ランサムウェア等で暗号化されたデータがバックアップにも同期され、戻しても同じ被害
• クラウド障害・アカウント乗っ取りなど「クラウドならでは」のリスクを想定していない

バックアップは「データを残す仕組み」、DR（Disaster Recovery：災害復旧）は「業務を再開する仕組み」です。両者は重なりますが同じではありません。たとえば、バックアップがあっても、復元に丸一日かかればECやコールセンターは止まります。逆に、DR環境があっても、直前のデータが欠けていれば二重入力や請求ミスが発生します。

この記事では、ITに詳しくない方でも合意形成しやすい形で、バックアップ/DRの要点と、RPO/RTOの決め方、そして失敗しない設計・運用の進め方を整理します。

まず押さえる用語：RPO/RTOと「守る対象」

バックアップ/DR設計で最重要なのがRPO/RTOです。難しそうに見えますが、意思決定に必要な質問はシンプルです。

例：朝9時に障害が起きたとき、RPOが「1時間」なら8時時点まで戻ればOK、RTOが「2時間」なら11時までに業務が再開できる必要があります。ポイントは、RPOはデータ、RTOは時間（業務停止）という違いです。

次に「守る対象」を分解します。多くの企業で「システム」と一括りにしてしまい、結果として設計が過剰（高コスト）か不足（復旧できない）になります。

• 業務（プロセス）：受注、出荷、請求、勤怠、問い合わせ対応など
• データ：顧客、注文、契約、会計、ログ、ファイル、メール
• アプリケーション：Web、API、バッチ、モバイル、管理画面
• 基盤：クラウドアカウント、ネットワーク、ID、DNS、証明書

特に見落とされがちなのが「IDと権限」「DNS」「証明書」「外部SaaS連携」です。データベースを戻せても、ログインできない、ドメインが切り替わらない、外部決済が動かない、という理由でRTOを満たせないことがあります。バックアップ/DRを設計するときは、データだけでなく、復旧に必要な“周辺部品”も対象に入れます。

RPO/RTOの決め方：非エンジニアでも合意できる5つの質問

RPO/RTOは「IT部門が決める数字」ではなく、事業の損失許容度から逆算します。とはいえ、厳密な計算が難しいことも多いので、まずは会話で決められる質問から始めるのが現実的です。最初の設計は“完璧”より“合意”が重要です。

質問1：止まると困る業務は何か（優先順位）

全システムを同じRTOにするとコストが跳ねます。業務をA（最優先）、B（早期復旧）、C（翌営業日でも可）に分けます。

• A：売上に直結（EC注文、決済、受注登録、倉庫出荷）
• B：社内効率（在庫照会、分析、社内ポータル）
• C：停止しても代替可能（社内申請、過去データ閲覧）

質問2：停止1時間あたりの損失はどれくらいか

損失は売上だけでなく、残業、違約金、機会損失、信用毀損、問い合わせ対応増を含みます。ざっくりで構いません。

• 売上：平均時給売上（例：1時間あたり50万円）
• 人件費：手戻り入力、二重対応（例：10人×2時間）
• 信用：SNS炎上、解約率上昇（定量化が難しければ重み付け）

この数字が分かると、RTOを短くする追加コスト（DR環境や多重化）との比較ができます。

質問3：どのデータが欠けると致命的か（RPOの焦点）

データ損失の影響は業務によって違います。たとえば会計仕訳は少量でも影響が大きい一方、アクセスログは多少欠けても許容できることがあります。

• 顧客・契約・請求：数分〜数時間でも困る（RPO短めが望ましい）
• 受注・在庫：失うと出荷や欠品に波及（RPO短め）
• 分析用データ：翌日復元でも可（RPO長めでOK）

質問4：手作業で代替できる時間はどれくらいか

「紙で受注する」「Excelに仮入力する」「電話で受ける」など代替策があると、RTOを少し緩められます。ただし、後でシステムに戻す作業（突合・二重入力）が発生します。代替策の“復旧後の後始末”まで含めて許容できるかを確認します。

質問5：最大被害シナリオは何か（クラウド特有も含む）

「サーバ故障」だけでなく、次のようなシナリオを想定すると設計の抜けが減ります。

• 設定ミスでデータ削除（人為ミス）
• ランサムウェアで暗号化（バックアップも巻き込まれる）
• クラウドアカウント乗っ取り（権限を奪われバックアップ削除）
• リージョン障害（広域障害）
• SaaS連携先の障害（決済、メール配信、CRMなど）

この質問で「バックアップは同一アカウント内だけで良いのか」「別リージョンに保管するか」「イミュータブル（改ざん不可）にするか」などの方針が決まります。

設計の全体像：バックアップとDRの代表パターン（コストと効果）

クラウドのバックアップ/DRは、目的と予算に応じて段階的に選べます。ここでは代表パターンを、非エンジニアでも判断しやすい観点で整理します。結論として、「全部を最上位」にするのではなく、業務重要度で分けるのが現実的です。

バックアップ中心（復旧は手動）

• 概要：定期バックアップを取り、障害時に復元する
• 向くケース：RTOが数時間〜翌日、RPOが数時間〜1日で許容される
• 注意：復元作業が属人化しやすく、手順書と訓練が必須

よくある落とし穴は「バックアップはあるが、復元に必要な設定・接続情報がない」ことです。DBの復元はできても、アプリ設定や接続先、秘密鍵、環境変数が分からず止まります。

パイロットライト型（最小限の待機環境）

• 概要：平時は小さく待機し、障害時にスケールして復旧
• 向くケース：RTOを短め（数十分〜数時間）にしたいが、常時二重化は高い
• 注意：切替手順と自動化がないと、結局RTOを満たせない

ウォームスタンバイ型（常時ある程度動かす）

• 概要：別環境で常時起動し、データも同期。切替で復旧を早める
• 向くケース：RTOを短く（数分〜数十分）したい基幹業務
• 注意：コスト増。同期方式次第でRPOが決まる

マルチサイト/アクティブ-アクティブ（最短復旧だが難易度高）

• 概要：複数拠点で同時稼働し、障害時も片側で継続
• 向くケース：停止が許されないサービス（金融、決済、社会インフラ級）
• 注意：設計・運用が難しく、アプリ側の作りも影響する

中小企業や「情シスが少人数」の組織では、最初から最上位を狙うと運用破綻しがちです。まずは重要業務の一部だけをウォームスタンバイにし、その他はバックアップ中心にするなど、重要度で層を分けるのがおすすめです。

失敗しないバックアップ設計：頻度・世代・保管・復元性を押さえる

バックアップは「取る」だけでは不十分で、復旧に使える状態である必要があります。設計の要点は、頻度（RPO）、復元時間（RTOへの寄与）、保管の安全性（改ざん耐性）、そして復元テスト（実効性）です。

バックアップ頻度と世代管理（いつまで残すか）

世代管理は「直近は細かく、古いものは間引く」が基本です。例として次のような設計がよく使われます。

• 直近24時間：1時間ごと
• 直近7日：1日ごと
• 直近3か月：週ごと
• 直近1年：月ごと

ここで重要なのは、RPOだけでなく“気づくまでの時間”を入れることです。誤削除や不正操作は、発生から数日後に発覚することがあります。気づいたときに戻せる世代が残っていないと詰みます。

バックアップの保管場所：同一環境だけに置かない

クラウドの利点で見落とされがちなのが「アカウントそのものが単一障害点になる」ことです。アカウント乗っ取りや誤操作で、バックアップも一緒に消される可能性があります。対策として、次を検討します。

• 別リージョン保管：広域障害対策
• 別アカウント保管：権限侵害・誤削除対策
• イミュータブル（一定期間削除不可）：ランサムウェア対策

「コストが心配」という場合は、すべてを別保管にせず、Aランク業務のデータだけを厳重にするなど、重要度で調整します。

バックアップ対象の抜け漏れを防ぐ（よく忘れるもの）

復旧時に困るのは「データベース」より、周辺設定が欠けているケースです。たとえば次の項目はチェックリスト化しておくと安全です。

• アプリの設定値（環境変数、接続先、機能フラグ）
• シークレット（APIキー、証明書、秘密鍵）
• DNS設定、ドメイン管理、証明書の更新手順
• ジョブ定義（バッチ、スケジューラ）
• 外部SaaS連携設定（Webhook、コールバックURL）
• 監査ログ、操作ログ（原因調査に必須）

「復旧に必要なものを丸ごと再現できるか」という視点で、データ以外も含めてバックアップ（または構成管理）します。

復元性の確保：バックアップは必ず“戻して試す”

バックアップは「取れている」ことと「戻せる」ことが別です。復元テストは最低でも四半期に一度、重要システムは月次も検討します。テストは本番を止めず、隔離環境で実施するのが一般的です。

• 復元手順書どおりに戻せるか（担当者が変わっても可能か）
• 復元後に業務が動くか（ログイン、検索、登録、バッチ）
• 復元にかかった時間（RTOを満たすか）

復元テストの結果は「何分で、誰が、どの手順で」まで記録し、次回改善につなげます。

DR（災害復旧）設計：切替手順・責任分界・訓練でRTOを守る

DRは「第二環境を用意する」だけでは成立しません。いざという時に切替できるよう、手順・権限・連絡体制・判断基準を整備し、訓練で短縮していきます。DRの本質は“技術”より“運用設計”です。

切替の判断基準（いつDRを発動するか）

迷っている時間が最も高くつきます。たとえば次のように基準を決めます。

• 停止が連続30分を超え、復旧見込みが立たない場合はDR検討開始
• 停止が60分を超える見込みならDR発動
• セキュリティ侵害が疑われる場合は“復旧より隔離”を優先

基準は業務影響（損失）とRTOに合わせます。「誰が最終判断するか」も決めておくと、意思決定が速くなります。

責任分界の明確化（クラウド事業者がやってくれる範囲）

クラウドでは、クラウド事業者が守るのは主に「基盤の可用性」であり、ユーザー企業は「データ・設定・権限・アプリ」を守る必要があります。たとえば、誤削除や権限ミスはユーザー側の責任です。ここを誤解すると、DR投資の優先順位を間違えます。

DRでよくある失敗：データ同期と整合性

DR環境にデータを同期していても、同期が片方向だったり、遅延が大きかったり、アプリの仕様上「二重書き込みができない」場合があります。また、障害時に同期を止めないと壊れたデータがDR側に伝播することもあります。RPOを満たしつつ“壊れたデータを広げない”設計が重要です。

DR訓練（机上ではなく、実際に切り替える）

DR訓練は、次の3段階で成熟させると現実的です。

1. 机上訓練：手順書を読み合わせ、判断基準と連絡を確認
2. 部分訓練：DNS切替、バックアップ復元、特定コンポーネントだけ復旧
3. 総合訓練：業務再開までの一連を実施し、RTOを計測

訓練の成果物は「RTO実測」「詰まった箇所」「改善タスク」です。これが積み上がると、DRが“絵に描いた餅”になりません。

導入手順のテンプレ：要件定義→設計→運用までの進め方

バックアップ/DRは一度作って終わりではなく、変更（システム追加、組織変更、法規制、委託先変更）に追随できる運用が必要です。ここでは、情シスや管理部門が進めやすいテンプレートを示します。

要件定義：業務基準でRPO/RTOを決め、合意文書にする

• 対象業務の棚卸し（A/B/C）
• 各業務のRPO/RTO（まずは仮でもよい）
• 対象範囲（DB、ファイル、SaaS、ID、DNS、ログ）
• 最大被害シナリオ（誤削除、ランサム、乗っ取り、リージョン障害）

この時点で経営・事業・情シスで合意を取ります。後から「そんなに止まると思わなかった」を防ぐためです。

基本設計：方式を決める（バックアップ中心/DRあり、保管、暗号化、アクセス制御）

• バックアップ方式：スナップショット、論理バックアップ、オブジェクト保管などの組み合わせ
• 保管：別リージョン、別アカウント、イミュータブルの有無
• 権限：バックアップ削除権限の分離、MFA、特権アカウント管理
• 監査：操作ログの保存、アラート（大量削除、権限変更）

セキュリティ面では「バックアップを消されない」ことが核心です。バックアップ担当と運用担当を分ける、削除に承認フローを入れるなど、組織的な対策も効きます。

詳細設計：復旧手順書とチェックリストを作る

手順書は“分かる人だけが分かる”状態を避け、第三者が読んでも再現できる粒度にします。

• 復旧の順序（例：ID→ネットワーク→DB→アプリ→DNS→外部連携）
• 復旧後の確認（ログイン、登録、帳票、バッチ、メール送信）
• 連絡手順（社内、取引先、顧客告知、委託先）
• 判断基準（DR発動、切戻し、隔離）

運用：監視、定期テスト、変更管理で“劣化”を防ぐ

システムは日々変わるため、バックアップ/DRは放置すると劣化します。最低限の運用ルールを決めます。

• バックアップ成功/失敗の監視と通知
• 復元テスト（四半期、重要は月次）
• システム変更時の更新（新機能追加・DB変更・外部連携追加）
• コスト監視（過剰な世代保持、不要データの肥大化）

特に「退職・異動」で手順が回らなくなるケースが多いので、ドキュメント化と訓練をセットにしておくと安心です。

まとめ

クラウドのバックアップ/DR設計を失敗しないための要点は、技術選定より先にRPO（どこまでのデータ損失を許容するか）とRTO（いつまでに再開するか）を業務基準で合意することです。次に、重要度でシステムを分け、バックアップ中心・パイロットライト・ウォームスタンバイなど方式を適材適所で組み合わせます。

• 「バックアップがある」だけでは不十分。復元テストで“戻せる”状態を証明する
• クラウド特有のリスク（乗っ取り、誤削除、ランサム、リージョン障害）を前提に、別アカウント/別リージョン/改ざん不可保管を検討する
• DRは環境だけでなく、判断基準・責任分界・訓練でRTOを守る

「何から決めればいいか分からない」「現状のバックアップでRPO/RTOを満たせるか不安」「DR訓練まで回らない」という場合は、業務の優先順位付けと現状評価から始めるのが近道です。