DRサイトとは？種類とRTO・RPO、構成の選び方を解説
DRサイトとは、災害や障害で本番環境が使えなくなったときに、システムを復旧・継続させるために用意しておく待機環境のことです。DRはディザスタリカバリ(Disaster Recovery)の略です。
AWSの公式解説では、ディザスタリカバリは停電・自然事象・セキュリティ問題などの技術関連の災害を予測して対処するプロセスと説明されています。
検討の軸になるのは、どれだけ早く復旧するか(RTO)と、どこまでのデータ損失を許容するか(RPO)の2つです。
本記事では、DRサイトの種類と、業務ごとに現実的な構成を選ぶ手順を解説します。
出典：AWS公式「ディザスタリカバリとは」、内閣府「事業継続 初めての方へ」（いずれも2026年9月25日確認）。
DRサイトとは何か。BCPの中での位置づけ
DRサイトは、事業継続の取り組み(BCP)の中で、情報システムの復旧を担う部分です。内閣府の事業継続の解説でも、BCPの典型的な内容として、バックアップのシステムやオフィスの確保、要員の確保、迅速な安否確認が挙げられています。つまりDRサイトは、BCP全体のうち「システムとデータをどう守り、どう復旧するか」に答えるための備えです。内閣府（2026年9月25日確認）。
なお、待機環境は本番と同じ場所に置いては意味が薄くなります。同じ建物・同じ電源・同じ回線に依存していると、災害時に同時に失われるためです。物理的に離れた拠点、またはクラウド上の別の地域に置くことが前提になります。
混同しやすい言葉に「バックアップ」があります。バックアップはデータの複製を保管することで、DRはそのデータを使って業務を再開できる状態まで戻すことを指します。データが残っていても、動かすサーバー・ネットワーク・手順・人がそろわなければ業務は再開できません。DRサイトの検討は、この「再開までの全体」を設計する作業です。
判断軸はRTOとRPO。2つの目標値を先に決める
AWSの公式解説では、RTO(目標復旧時間)は「ディザスタリカバリを完了するまでに経過する最大時間」、RPO(目標復旧時点)は「災害後にデータ損失が許容される最大時間」と定義されています。RPOを短くするほど、より頻繁・継続的なバックアップが必要になります。AWS公式（2026年9月25日確認）。
実務では、この2つを業務ごとに言葉で決めるところから始めます。「受注システムは半日以内に再開したい。失ってよいのは直近1時間分まで」「社内の勤怠は3日止まっても締めに間に合う」のように、業務部門が答えられる形で置くことが重要です。RTO・RPOを短くするほど構成は高価になるため、この目標値が、かける費用の根拠になります。目標値を決める場には、情報システム部門だけでなく業務部門の責任者を必ず入れてください。どこまで止まってよいかは技術ではなく事業の判断であり、後から「そんなに止まるとは聞いていない」となる原因の多くは、この場に業務側がいないことです。
DRサイト・DR方式の種類
AWSの公式解説では、ディザスタリカバリの方法として、データをオフサイトやクラウド・外部媒体に保存するバックアップ、消火・バックアップ電源などデータセンター側の対策、オフサイトの仮想マシンへ複製する仮想化、クラウドで復旧環境を提供するDRaaS(サービスとしてのディザスタリカバリ)、別の物理拠点に業務を移すコールドサイトなどが挙げられています。AWS公式（2026年9月25日確認）。
待機環境は、一般に準備の度合いに応じて次のように呼び分けられます。
| 呼び方 | 待機環境の状態 | 向く場面 |
|---|---|---|
| ホットサイト | 本番とほぼ同じ環境を常時稼働させておく | 停止がただちに損害へ直結する業務 |
| ウォームサイト | 縮小構成や停止状態の環境を用意し、切替時に立ち上げる | 復旧の速さと費用の両立を図りたい業務 |
| コールドサイト | 場所・最小限の設備のみ確保し、発動時に構築する | 停止許容時間が長い業務 |
この3分類は呼び方の整理であり、切替にかかる具体的な時間は構成によって異なります。準備の度合いを上げるほど費用は増えるため、前節のRTO・RPOに合わせて選びます。
構成を選ぶ手順。全システムを同一水準にしない
発注・検討の実務で重要なのは、すべてのシステムを同じ水準で守ろうとしないことです。手順は次の通りです。
第1に、システムの一覧を作り、業務への影響で優先度を分けます。第2に、優先度ごとにRTO・RPOを決めます。第3に、それを満たす最小の方式(バックアップのみ・ウォーム・ホット)を割り当てます。このとき、システム同士の依存関係も書き出します。優先度の高い受注システムが、優先度を低く付けた認証基盤や共有データベースに依存している場合、実際の復旧順序は依存先が先になります。一覧には「このシステムが動くために必要なもの」の列を設けてください。第4に、切替の判断者と発動基準を決めます。技術的に切替可能でも、「誰がいつ発動を決めるか」がないと復旧は始まりません。第5に、年に1度は復旧手順の訓練・リハーサルを行い、手順書と実環境のずれを直します。
クラウドサービスやノーコード基盤の上で動くシステムでも、この考え方は同じです。基盤側の可用性と、自社データの復元手順は別問題のため、契約で「事業者が何を復旧してくれるか」「自社で何を戻す必要があるか」を確認してください。具体例として、Bubbleで作ったアプリの場合の考え方をBubbleアプリのバックアップと復元手順で解説しています。
DR環境の維持は継続費用でもあります。保守費用の考え方を参考に、監視・訓練・環境維持を年間の運用費として計上してください。
DRサイトに関するFAQ
DRサイトとバックアップはどちらを先に整備すべきですか？
まずバックアップです。復元できるデータがなければ、どんな待機環境があっても業務は戻せません。復元テストは「バックアップから実際に業務画面を開けること」までを確認の基準にしてください。バックアップの取得と復元テストを確立したうえで、復旧の速さが足りない業務にだけ待機環境の強化を検討する順序が現実的です。
DRサイトの構築費用はどのくらいかかりますか？
構成(方式・対象システム・データ量)によって大きく異なるため、本記事では一律の相場を示していません。費用を比較する際は、初期構築だけでなく、待機環境の利用料、訓練、手順書の維持を含めた年間費用でそろえてください。
クラウドを使っていればDRサイトは不要ですか？
クラウドの利用だけでは十分とはいえません。基盤の障害対策は事業者側にあっても、操作ミスやデータ破損からの復元、設定の再現、業務手順の復旧は利用者側の設計に依存します。自社のRTO・RPOを決めたうえで、契約内容と復元手順を確認してください。
復旧優先度の整理からシステムの設計まで相談できます
ノーコード総研では、ノーコードやAIを活用した業務システムの受託開発をご相談いただけます。新しくシステムを作る際に、バックアップ・復旧の要件を最初から設計へ含めることで、後付けのDR対策より無理のない構成にできます。
個別開発の費目はシステム開発費用の内訳で確認できます。まずは止まると困るシステムと許容できる停止時間を書き出して、ノーコード総研に相談することから始めてみてください。