クラウドバックアップの設計｜DR対策に必要なRPO・RTOの考え方災害復旧（DR）対策に必要なクラウドバックアップ設計の基礎を、RPO・RTOの概念とともに中小企業向けに解説

「バックアップは取っている」だけでは事業は守れない

地震、台風、豪雨といった自然災害に加え、ランサムウェア攻撃やヒューマンエラーによるデータ消失——企業のITシステムが停止するリスクは年々高まっています。多くの企業が「バックアップは取っている」と答えますが、「そのバックアップで、何時間以内に業務を再開できますか」「何日前のデータまで戻せますか」と問われると、明確に答えられない企業が少なくありません。災害復旧（DR：Disaster Recovery）対策の核心は、単にデータを保存することではなく、「どの時点のデータに」「どれだけの時間で」復旧できるかを設計することです。本記事では、DR対策の基本指標であるRPOとRTOの概念を解説し、中小企業がクラウドバックアップを正しく設計するための考え方を紹介します。

RPOとRTOの基本概念

DR対策を設計するうえで、まず理解すべき2つの指標があります。

RPO（Recovery Point Objective：目標復旧時点）は「障害発生時に、どの時点のデータまで戻せれば許容範囲か」を定める指標です。RPOが24時間であれば「前日の状態に戻せればよい」という意味であり、バックアップは1日1回の頻度で足ります。RPOが1時間であれば、1時間ごとのバックアップが必要になります。RPOが0に近い（データ消失をほぼ許容しない）場合は、リアルタイムのレプリケーション（複製）が求められます。

RTO（Recovery Time Objective：目標復旧時間）は「障害発生から、どれだけの時間でシステムを復旧させるか」を定める指標です。RTOが24時間であれば「翌日までに復旧すればよい」、RTOが1時間であれば「1時間以内に業務を再開する必要がある」ということです。

重要なのは、RPOとRTOは必ずセットで設定するという点です。「前日のデータに戻せる」（RPO＝24時間）としても、復旧に3日かかる（RTO＝72時間）のであれば、3日間の業務停止を受け入れることになります。RPOとRTOを組み合わせて初めて、自社のDR対策の「水準」が定まります。

「すべて即時復旧」は現実的ではない

RPOもRTOも短ければ短いほど、データ消失と業務停止のリスクは下がります。しかし、短く設定するほどDR対策のコストは指数関数的に上がります。リアルタイムレプリケーションとホットスタンバイ（常時稼働の待機系）を組み合わせればRPO・RTO共にほぼゼロにできますが、その維持コストは中小企業の予算を大幅に超えるのが通常です。

中小企業にとって現実的なアプローチは、システムごとにRPOとRTOを差別化することです。たとえば、ECサイトの受注データは「RPO＝1時間、RTO＝4時間」と厳しめに設定する一方、社内の人事情報システムは「RPO＝24時間、RTO＝48時間」で十分かもしれません。すべてのシステムを同じ水準で保護するのではなく、業務の重要度に応じてメリハリをつけることで、コストと保護レベルのバランスを取ることができます。

この差別化の判断基準となるのが「ビジネスインパクト分析（BIA）」です。各システムが停止した場合に発生する売上損失、顧客への影響、法的リスク、ブランドへのダメージを評価し、その影響の大きさに応じてRPO・RTOの優先度を決定します。BIAは大企業だけのものと思われがちですが、中小企業でも「このシステムが1日止まったら、いくらの売上を失うか」を概算するだけで、優先順位の判断材料として十分に機能します。

クラウドバックアップの5つの設計パターン

RPO・RTOの目標が定まったら、それを実現するためのバックアップ方式を選定します。クラウドを活用したDR設計には、コストとRPO・RTOの組み合わせに応じた段階的なパターンがあります。

パターン1は「日次バックアップ＋手動リストア」で、RPO24時間・RTO24〜48時間の水準です。AWSのS3やAzureのBlob Storageにデータを1日1回自動バックアップし、障害時には手動でリストアします。最も低コストで導入が容易ですが、復旧に時間がかかります。更新頻度の低い社内システムや参照系データに適しています。

パターン2は「スナップショット＋コールドスタンバイ」で、RPO数時間・RTO4〜12時間の水準です。仮想マシンのスナップショットを定期的に取得し、障害時にはスナップショットから新しいインスタンスを起動して復旧します。AWSのEBSスナップショットやAzureのマネージドディスクスナップショットが該当します。

パターン3は「増分バックアップ＋ウォームスタンバイ」で、RPO1〜4時間・RTO1〜4時間の水準です。増分バックアップを数時間おきに取得し、待機系のサーバーを低スペックで常時起動しておきます。障害時にはスペックを引き上げてバックアップデータを適用し復旧します。コストと復旧速度のバランスが良く、中小企業の基幹システムに適しています。

パターン4は「マルチリージョン＋ホットスタンバイ」で、RPO数分・RTO数分〜1時間の水準です。異なるリージョンにデータをほぼリアルタイムで複製し、待機系を常時稼働させます。障害時にはDNSの切り替えだけで復旧が完了します。高コストですが、ECサイトや顧客向けサービスなどダウンタイムが直接売上に影響するシステムに適しています。

パターン5は「リアルタイムレプリケーション＋自動フェイルオーバー」で、RPO・RTOともにほぼゼロの水準です。すべてのトランザクションをリアルタイムで複製し、障害検知時に自動で待機系に切り替わります。金融機関や医療機関など、秒単位の停止も許容できない業務に限定されるレベルです。

「3-2-1ルール」を基本に設計する

バックアップ設計の基本原則として広く知られているのが「3-2-1ルール」です。データのコピーを3つ作成し、2種類以上の異なるメディアに保存し、そのうち1つは物理的に離れた場所（オフサイト）に保管するという考え方です。

クラウド時代においても、この原則の重要性は変わりません。たとえば、本番環境のデータ（1つ目）に加えて、同一リージョンのクラウドストレージへのバックアップ（2つ目）、そして別リージョンまたはオンプレミスのNASへのバックアップ（3つ目）を確保する構成が、中小企業にとって現実的な3-2-1ルールの実装です。

特に注意すべきは、ランサムウェア対策として「イミュータブル（変更不可能な）バックアップ」を確保することです。AWSのS3 Object LockやAzureの不変ストレージ機能を使えば、一定期間はバックアップデータの削除や改ざんができない状態を作れます。ランサムウェアに感染した場合でも、このバックアップからクリーンな状態に復旧できます。

設計後に必ずやるべきこと——復旧訓練

バックアップ設計で最も見落とされがちなのが「復旧訓練」です。「バックアップは取れているが、いざ復旧しようとしたら手順がわからなかった」「復旧に想定以上の時間がかかった」「バックアップデータが破損していて使えなかった」という事態は、訓練を行っていない企業で頻繁に発生します。

半年に1回のペースで、実際にバックアップデータからシステムを復旧する訓練を実施しましょう。訓練では、復旧手順書に沿って作業を行い、実際のRTOが目標値を達成できるかを計測します。また、復旧したデータの整合性（データが欠損していないか、最終更新時刻がRPO以内に収まっているか）も検証してください。

訓練で得られた知見（想定と実際のRTOの差、手順の不備、担当者の不在時の対応方法など）を復旧手順書にフィードバックし、継続的に改善することが、DR対策の実効性を担保する唯一の方法です。DR対策は「作って終わり」ではなく、事業やシステムの変化に合わせて定期的に見直し、訓練で検証し続けるサイクルが不可欠です。

GXOのインフラ設計支援

DR対策は「万が一」に備える投資ですが、その設計の品質が、実際に災害が起きたときの事業継続力を左右します。GXOは180社以上の支援実績と92%の成功率を持つDX・システム開発のパートナーとして、RPO・RTOの設定からバックアップアーキテクチャの設計、復旧手順の策定と訓練支援まで一気通貫でサポートしています。

「自社のバックアップ設計が適切か不安」「DR対策のコストと効果のバランスがわからない」「ランサムウェア対策を含めた設計を見直したい」という方は、お気軽にご相談ください。御社の業務特性とシステム構成に最適なDR設計をご提案します。

お問い合わせはこちら

まとめ

クラウドバックアップのDR設計は、RPO（どの時点のデータに戻すか）とRTO（どれだけの時間で復旧するか）の2つの指標を起点に組み立てます。すべてのシステムを即時復旧しようとするとコストが膨大になるため、業務の重要度に応じてRPO・RTOを差別化し、5つの設計パターンから最適な方式を選定することが中小企業の現実解です。3-2-1ルールに基づくバックアップ構成を整え、ランサムウェア対策としてイミュータブルバックアップを確保し、半年に1回の復旧訓練でDR対策の実効性を検証する——この3つを着実に実行することが、災害に強い事業基盤の構築につながります。