BCPとDRの違いを比較表で解説｜RPO・RTOと情報処理安全確保支援士の出題【SC試験対策】

企業を取り巻くリスクは、自然災害からサイバー攻撃まで多岐にわたります。こうした危機的状況で組織が生き残れるかどうかは、事前の準備次第です。

その準備の中核が「BCP」と「DR」ですが、この2つは混同されがちです。結論を先に言うと、BCP（事業継続計画）は事業全体を守る計画、DR（災害復旧）はその中でITシステムを復旧させる計画で、DRはBCPの一部という包含関係にあります。本記事ではBCPとDRの違いを冒頭の比較表で一気に整理したうえで、RPO/RTOなどの重要指標、バックアップサイト戦略、そして情報処理安全確保支援士（SC）試験での問われ方まで解説します。

BCPとDRの違いを比較表で理解する

BCPとDRは密接に関連していますが、その対象範囲・目的・主体は明確に異なります。まずは下の比較表で違いの全体像をつかんでください。細部の理解はこの後のセクションで補強します。

観点	BCP（事業継続計画）	DR（災害復旧）
正式名称	Business Continuity Plan	Disaster Recovery（計画を指す場合はDRP：Disaster Recovery Plan）
守る対象	事業全体（人・拠点・資金・サプライチェーン・IT）	ITシステムとデータ
目的	事業を継続・早期再開させる	停止したシステムを復旧させる
主体・責任者（一般的な分担の例）	経営層・各事業部門	CIO・システム管理者・IT部門
主な活動	安否確認、代替オフィス、危機広報、資金確保	データ復元、フェイルオーバー、通信経路再構築
包含関係	DRを含む上位の計画	BCPを実現するIT手段（下位）
視点	経営・マネジメント視点	技術・運用視点

主体・責任者の欄は一般的な分担の例です。実際の権限・分担は、組織の規程で定めます。

ひと言でまとめると、BCPは「ビジネスをどう続けるか」、DRは「ITをどう直すか」です。この主語の違いを押さえれば、両者の違いを問う問題で迷うことはなくなります。以下、それぞれを詳しく見ていきます。

BCPとDRの違いを左右2列で比較した図解。左のBCPは経営視点で事業全体（人・拠点・資金・IT）を守り、右のDRは技術視点でITシステムとデータを復旧する。両パネルを囲む破線がBCPがDRを内包する包含関係を示す。

BCP：事業全体を守る包括的な戦略

BCP（Business Continuity Plan）は「事業継続計画」を意味し、予期せぬ事態が発生しても事業を継続させる、または最短時間で再開させるための総合的な行動計画です。

BCPの対象範囲はITシステムに限定されません。以下のような要素を含む包括的な計画です。

従業員の安全確保と安否確認システムの運用
代替オフィスの確保と指揮命令系統の移転
緊急時の資金調達と決済手段の確保
サプライチェーンの代替調達先の選定
顧客・株主・メディアへの危機広報対応

BCPは「ビジネス」を主語とした、組織の生存戦略そのものです。

DR：ITシステムに特化した復旧計画

DR（Disaster Recovery）は「災害復旧」を意味し、BCPの一部として、特にITシステムとデータの復旧に焦点を当てた取り組みです。その手順や体制を文書にまとめた計画を指す場合は、DRP（Disaster Recovery Plan：災害復旧計画）と呼びます。

現代のビジネスでは、ITシステムの停止は多くの業務で事業の停止に直結します。そのため、DRはBCPの中で極めて重要な位置を占めますが、あくまで「BCPという目的を達成するためのIT手段」として位置づけられます。

DRの主な活動内容は以下の通りです。

バックアップデータの復元（リストア）手順の実行
予備サーバーへの切り替え（フェイルオーバー）
ネットワーク通信経路の再構築

包含関係の理解が試験突破の鍵

BCPは組織全体の戦略であり、その中にITシステム部門が担当するDRが含まれる構造です。一般的な分担の例としては、BCP策定は経営層や各事業部責任者が主体となり、DR策定はCIO（最高情報責任者）やシステム管理者が中心的役割を果たします。

BCP（事業継続計画）という大きな枠組みの中に、「従業員の安全確保」「代替オフィス・指揮命令系統」「資金・決済手段」「サプライチェーン」「危機広報」の各要素と、中央にDR（ITシステムの復旧）が1つだけ含まれていることを示す包含関係図。DRはBCPを構成する要素の1つという位置づけを表す。

図のように、DRはBCPを構成する要素の1つであり、人・拠点・資金・取引先・広報といった他の要素と並んでBCPの中に含まれます。両者の連携が不十分だと「システムは復旧したが社員が出社できない」「社員は無事だがシステムが動かず業務処理ができない」といったミスマッチが発生します。BCPとDRの違いを暗記するだけでなく、この連携の視点まで理解しておくと、科目B（旧午後）の事例問題も読み解きやすくなります。

無料メール講座登録特典FREE PDF

SC午後記述テンプレート集

設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。「知っているのに書けない」を解消する1冊です。

設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し

無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

復旧計画を数値化する4つの重要指標（RPO・RTO・RLO・MTPD）

BCP/DRを具体化する際、避けて通れないのが「時間の指標」です。情報処理安全確保支援士試験でも問われやすい論点であり、BCPとDRをつなぐ共通言語でもあります。

RPO（Recovery Point Objective：目標復旧時点）

障害時に「どの時点までのデータを復元する必要があるか」という目標で、許容するデータ損失の範囲を定めます。

RPOを24時間と定めた場合：復元可能なバックアップの取得時点の間隔が24時間以内で、障害時にもそのバックアップを利用できるなら満たせる（取得の失敗や遠隔保管への転送遅れがあると、失うデータが24時間分を超えることがある）
RPOをゼロにする構成：同期レプリケーション等で、書き込みが複製先にも反映されたことを保証する必要がある（非同期レプリケーションでもほぼゼロに近づけられるが、複製の遅延に応じたデータ損失が生じうる）

RPOを短くするほど、システム投資額は増える傾向があります。業務の重要度とコストのバランスが重要です。

RTO（Recovery Time Objective：目標復旧時間）

「災害発生からどれくらいの時間でシステムを再稼働させるか」を示す指標です。許容されるダウンタイムの長さを定義します。

ECサイト：災害発生から3時間以内に再開
社内文書管理システム：24時間以内に再開

RTOが短いほど、高可用性を実現するための冗長化投資が必要になります。また、RTOはあくまで目標値であり、実際にその時間で復旧できるかは復旧テストで確かめます。ここで学び始めの人がつまずきやすいのが、RPOとRTOの取り違えです。RPOは過去方向（どこまでのデータを守るか）、RTOは未来方向（いつまでに動かすか）と、時間軸の向きで区別すると混同しません。

RLO（Recovery Level Objective：目標復旧レベル）

「どの程度の性能や機能で復旧させるか」を示す指標です。完全復旧か縮退運転かを定義します。

平常時100%の処理能力 → 非常時は重要顧客のみ対応する50%の能力で稼働
全機能の提供 → 注文受付機能のみに限定した縮退モード

緊急時に全ての機能を完全復旧させるのは現実的でない場合が多く、優先順位に基づいた段階的復旧を計画します。RLOはRTOと組み合わせて設定するのが一般的です。

MTPD（Maximum Tolerable Period of Disruption：最大許容停止時間）

業務停止の影響が許容できなくなる限界の時間（停止時間の許容限界）です。BIA（ビジネスインパクト分析）で、法令・契約（SLA等）・財務・信用への影響を時系列で評価して見極めます。

RTOはMTPDよりも短く設定します（RTO < MTPD）。復旧作業が想定より遅れる場合に備え、余裕を持たせた設定が求められます。

災害発生を基準にしたタイムライン図。左側には、最後のバックアップ時点から災害発生までの幅としてRPOを示す。右側には、災害発生から目標復旧時刻までをRTOとし、その時点でサービスレベルがRLOに達する。さらにその後ろにMTPD（停止の許容限界）を置き、RTOがMTPDより短い（RTO＜MTPD）関係を示す。図中に「目標どおりに復旧できた場合の例」と明記している。

図は、目標どおりに復旧できた場合の例です。災害発生を基準に、左側の最後のバックアップ時点から災害発生までの幅がRPO（失いうるデータの範囲）、右側の災害発生から目標復旧時刻までがRTOで、その時点でサービスはRLOで定めたレベルに達します。MTPDはさらにその先にある停止の許容限界であり、RTOはその手前に収める必要があります。

これらの指標は、システム部門だけで決定できません。「ECサイトが1日停止すると1億円の損失が発生するため、コストをかけてでもRTOは1時間以内にする」といった、BIA（ビジネスインパクト分析）の結果に基づく経営判断が必須です。ここにも、経営視点のBCPと技術視点のDRが交わる接点があります。

バックアップサイト戦略：コストと復旧速度のトレードオフ

DR（災害復旧）の中核となるのが、メインセンターが被災した際に切り替える「バックアップサイト（副センター）」の構築です。コストと復旧速度のバランスを考慮したサイト選定は、試験でも問われやすい論点です。

ホットサイト（Hot Site）：最短の復旧を狙う高コスト型

本記事では、本番相当の設備・データ・要員を整え、短時間で切り替えられる拠点の例として説明します（切り替えの所要時間は構成によります）。

特徴

本番環境のデータを継続的に複製し、短時間で業務を切り替えられる構成にできる
RTO、RPOともに短く設定しやすい

メリット

復旧が最も速くなりやすい
データ損失を小さく抑えやすい

デメリット

本番相当の設備・回線・要員を維持するため、最も高コストになりやすい

なお、同期レプリケーションは論理破損やランサムウェアによる暗号化も複製するため、世代管理されたバックアップと併用します。

適用が検討される例

証券取引システム
銀行の勘定系システム
救命救急センターの医療情報システム

ウォームサイト（Warm Site）：中間的なバランス型

機器や回線は設置済みですが、最新のソフトウェア・データの投入（バックアップからのリストア等）や設定が必要な拠点です。本番より性能の低い機器を配置する場合もあります。

特徴

災害発生後にバックアップからデータをリストアし、設定を済ませてからアプリケーションを起動する
復旧には、システムの複雑さとデータ量により数時間〜数日かかる（NIST SP 800-34の目安）

メリット

ホットサイトより大幅に低コスト
一定の復旧速度を確保

デメリット

復旧作業に人員と時間が必要
最後のバックアップ以降のデータは失われる

適用が検討される例

社内業務システム
メールサーバー
日次更新のWebサイト

なお、ここでいうホット・ウォーム・コールドは拠点の準備度（サイト区分）による分類です。待機系サーバーがどこまで稼働しているかを示すホット・ウォーム・コールドスタンバイ（スタンバイ方式）とは別の軸で、名前が似ていても同じ意味ではありません。スタンバイ方式はRPOとRTOの違いとバックアップ戦略の記事で解説しています。

コールドサイト（Cold Site）：最小コストの長期復旧型

場所と、電源・空調・通信回線などの基本設備のみを確保し、機材は災害発生後に調達・搬入する方式です。

特徴

機器の調達・設置・テスト・データ投入が必要で、規模や複雑さにより数日〜数週間以上かかる

メリット

維持コストが最も安価
場所と基本設備（電源・空調・回線）の確保だけで済み、機器を常時保有しなくてよい

デメリット

復旧に長時間を要する
緊急時の機材調達リスク（在庫切れ等）が存在

適用が検討される例

重要度が低いシステム
長期間停止しても代替手段（紙運用など）があるシステム

ホットサイト・ウォームサイト・コールドサイトを3列で比較した図解。各列に拠点の状態、復旧までの目安、コストを並べている。ホットサイトは本番相当の設備・データ・要員を用意し、復旧は短時間（構成による）、コストは高い。ウォームサイトは機器・回線は設置済みだがデータ投入・設定が必要で、復旧は数時間〜数日、コストは中程度。コールドサイトは場所・電源・空調・回線のみで機器の調達・設置が必要なため、復旧は数日〜数週間以上、コストは低い。図の下に、復旧時間の目安はNIST SP 800-34によるもので、実際の時間は規模・構成・データ量で変わると注記している。

クラウド時代のDR戦略：Multi-Region / Multi-AZ構成

近年は、物理的なバックアップサイトを自社で構築する代わりに、AWS・Azure・Google Cloudなどのパブリッククラウドを活用する方法も選択肢として広く使われています。

マルチAZ（Availability Zone）構成

同一リージョン（例：東京）内の物理的に離れたデータセンター間で冗長化する方式です。

データセンター単位の火災や停電には対応可能
大規模震災（東京直下型地震など）には耐えられない可能性がある

マルチリージョン構成

東京リージョンと大阪リージョンなど、地理的に遠隔地で冗長化する方式です。

方式によっては、物理的なバックアップサイトを持つより低コストにできる
広域災害でも、別リージョンでシステムを継続・復旧しやすい

AWSのDRホワイトペーパーでは、クラウドでのDR方式を次の4つに整理しています（上ほど低コスト、下ほど復旧が速い）。

バックアップ＆リストア：平常時はバックアップを別リージョンに保管し、災害後に環境を構築して復元する
パイロットライト：データを別リージョンへ継続的に複製し、中核のインフラは用意したうえで、アプリケーションサーバーなどは災害時に起動・拡張する
ウォームスタンバイ：本番を縮小した環境を別リージョンで常時稼働させ、データを継続的に複製しておく
マルチサイトアクティブ/アクティブ：複数リージョンで同時に本番トラフィックを処理する

AWSのウォームスタンバイは、継続的に複製する縮小環境を指し、本記事のウォームサイト（データ投入や設定が必要な拠点）とは別の定義です。用語の名前ではなく、BIAで決めたRTO・RPOを満たせるかで方式を選ぶことが大切です。

BIA（ビジネスインパクト分析）：守るべき優先順位の決定

「サーバーを二重化する」といった技術論から入るのは、失敗するBCPの典型例です。まず「何を守るべきか」を明確にする分析が必要です。それがBIA（Business Impact Analysis：ビジネスインパクト分析）です。

内閣府「事業継続ガイドライン」の考え方に沿うと、BIAは「業務の洗い出し→停止影響の時系列評価→重要業務・優先順位の決定と目標案の設定」の順に進めます。目標は、その後に戦略・対策の実現可能性を検討したうえで、経営判断で最終決定します。

ステップ1：対象業務の洗い出し

組織内の業務をリストアップし、評価の対象を明らかにします。この段階ではまだ優先順位を決めず、漏れなく洗い出すことを優先します。

ステップ2：停止した場合の影響の時系列評価

洗い出した業務が停止した場合の影響を、停止期間が延びるにつれてどう変わるかという時系列で、定量的・定性的に評価します。

定量的評価（数値化可能な損害）

売上損失額の算出
違約金の発生額
復旧作業の人件費

定性的評価（数値化困難な損害）

企業の社会的信用の失墜
ブランドイメージの低下
顧客離れによる長期的な売上減少

これらの影響を、法令・契約（SLA等）上の制約も含めて時系列で整理し、業務ごとに「いつまでなら停止の影響を許容できるか（MTPD）」を見極めます。

ステップ3：重要業務・優先順位の決定と目標案の設定

評価結果をもとに、重要業務とその優先順位を決め、RTOなどの目標案を設定します。この段階の目標はあくまで案であり、戦略・対策の実現可能性を検討した後、経営判断で最終決定します。

たとえば「給与支払いシステムが1週間遅延しても事業は続けられるが、顧客からの受注システムが1日停止すると信用を失い、顧客が競合他社に流出する」と評価されれば、受注業務を優先して復旧させる、といった判断です。

ここで重要業務と判断されたものが、BCP/DR対策の最優先対象となります。MTPDはRTO（目標復旧時間）設定の根拠となります。

ステップ4：依存リソース（ボトルネック）の洗い出し

重要業務を継続・復旧させるために不可欠なリソース（経営資源）を特定します。

ITリソース

サーバー、ストレージ、ネットワーク機器
PC、タブレット等のエンドポイント
SaaSアカウントとライセンス

人的リソース

システム運用担当者
保守ベンダーの技術者
承認権限を持つ管理者

物理リソース

オフィススペース
電力供給設備
特殊な帳票用紙や専用機器

「業務Aを継続するためにはシステムBが必要だが、システムBはサーバーCとネットワークDに依存している」といった依存関係まで整理しておくと、どこが単一障害点になるかが見えてきます。

リスクアセスメント：脅威の特定と優先順位付け

BIAで「守るべきもの」が明確になったら、次は「何から守るか」を分析します。これがリスクアセスメントです。

全ての脅威に完璧に備えることは予算的に不可能です。発生確率と影響度をマトリクスで評価し、対策の優先順位を決定します。

主要な脅威の分類

自然災害

地震、津波
台風、洪水
落雷、豪雪

ハザードマップで拠点ごとの想定被害を把握し、リスク評価の材料にします。

人為的災害

火災
人的操作ミス
内部不正による破壊行為

技術的脅威

ランサムウェア攻撃
DDoS攻撃
ハードウェア故障
通信回線の障害

社会的脅威

パンデミック
テロリズム
大規模暴動

サイバー攻撃の脅威増大とDR戦略の進化

従来のDRは物理障害対策が中心でしたが、現在は「サイバー攻撃からの復旧」も同等以上に重要です。

特にランサムウェア攻撃では、「バックアップデータも暗号化されて復元不可能になる」事態が起こりえます。これに備えるため、以下の対策が有効です。

バックアップデータのオフライン保管・隔離（テープの搬出保管、ネットワークから切り離したエアギャップ環境）
イミュータブル（変更不可）ストレージの活用：保持期間中の変更・削除を制限する（モードによっては特権で解除できるため、管理者の権限も分離する）
バックアップシステムへのアクセス権の厳格な制限
世代管理による複数時点のバックアップ保持

イミュータブルストレージは「保持期間中の書き換え・削除を制限する」対策、オフライン保管は「ネットワークから切り離す（隔離する）」対策で、別の対策です。両者を組み合わせて使います。

有事の指揮系統：組織体制とコミュニケーション設計

完璧な書類上の計画があっても、人が適切に動けなければ意味がありません。BCP発動時の組織体制（対策本部）を明確に定義しておく必要があります。

役割分担の明確化

以下は対策本部の体制の一例です。実際の権限・分担は、組織の規程で定めます。

対策本部長

社長または役員が担当
BCP発動の最終決定
撤収・通常運転への復帰判断

情報収集班

被害状況の集約
社員の安否確認
交通機関・ライフラインの状況把握

対外対応班

顧客への状況説明と謝罪
メディア対応窓口
取引先への連絡

システム復旧班

IT担当者と保守ベンダーで構成
DR手順の実行
復旧状況の報告

エスカレーションルールの策定

「誰が、どのような状況で、誰に報告するか」という連絡網（連絡フロー）を整備します。

平時の連絡手段（社内チャットやメール）が使用不可能な状況を想定し、以下のような多重化された連絡手段を用意します。

安否確認システム（専用サービス）
衛星電話
複数キャリアの携帯電話（音声通話・SMS）
事前に指定した集合場所

ランサムウェア感染などのインシデントでは、担当者が独自判断でサーバーを再起動すると、メモリ上の情報など揮発性の証拠が失われ、調査が難しくなることがあります。対策本部の指示に従い、隔離→証拠保全→復旧の順と、その判断者を事前に決めておきます。

計画の陳腐化を防ぐ：訓練と維持管理のPDCAサイクル

BCP/DR策定の最大の敵は「陳腐化」です。計画策定の翌月にシステム構成が変更されたり、担当者が退職したりすることは珍しくありません。

「手順書のパスワードが古い」「バックアップテープの保管場所が変わって不明」といった事態を防ぐため、PDCAサイクルによる継続的な改善が必須です。なお、本記事のPDCAは改善活動を整理した独自の例であり、後述するISO 22301の箇条構成とは対応が異なります。

BCPのテスト・演習手法

机上演習（テーブルトップ演習）

関係者が会議室に集まり、計画書を読み合わせながらシミュレーションを実施します。

「この担当者に連絡がつかない場合の代替手段は何か」
「この手順で本当にシステムが復旧するか」

といった矛盾点や抜け漏れを洗い出すのに効果的です。比較的低コストで実施できる基本的な訓練方法です。

シミュレーション訓練

特定のシナリオ（例：日曜深夜のランサムウェア感染発覚）に基づき、実際に連絡網を回したり、模擬的な意思決定を行います。

時間的制約の中で適切な判断ができるか、連絡手段が実際に機能するかを検証できます。

システム切り替え訓練（DR訓練）

実際に本番系を停止（またはネットワーク遮断）し、バックアップサイトへの切り替えを実行します。

最も実効性が高い訓練ですが、業務影響のリスクも伴うため、入念な準備と経営層の承認が必要です。切り替え後の動作確認、切り戻し手順の確認まで含めて実施します。

BCP/DRの維持管理における改善活動を、本記事独自にPDCAで整理した例の図（ISO 22301の箇条構成とは対応が異なる）。Plan（リスク評価・BIA）、Do（計画策定・教育・訓練）、Check（テスト・演習・監査）、Act（是正処置・計画更新）の循環プロセスを表現。

計画のメンテナンスタイミング

定期的な見直し

年1回など、決まった時期に計画を見直す
訓練結果や監査指摘事項を反映

イベント発生時の見直し

大規模な人事異動（担当者の変更）
システムの更改や構成変更
オフィスの移転・統廃合
新たな法的規制の施行

ISO 22301:2019（事業継続マネジメントシステム：BCMS。Amd 1:2024で気候変動の考慮を追加）、国内規格のJIS Q 22301:2020に基づく認証では、これらの維持管理プロセスも審査の対象になります。国内では内閣府「事業継続ガイドライン」も策定・運用の指針として広く参照されており、認証取得や公的指針への準拠は取引先や顧客への信頼性アピールにもつながります。

SC試験での出題パターンと対策

BCPとDRは、科目A-1（旧午前I）で復旧指標の定義・分類が問われた例があります。ここでは、IPAの公開問題で確認できる過去問と、科目B（旧午後）の事例を読むときの着眼点、問われやすい論点を整理します。

科目A-1（旧午前I）：RTO・RPO・RLOの定義と分類

科目A-1（旧午前I）では、復旧指標の定義・分類が問われた例があります（令和6年度秋期高度共通午前I 問20）。

過去問で確認：RTOとRLOを定めた例（令和6年度秋期高度共通午前I（現科目A-1）問20）

サービスを復旧させるときの目標を定める指標としてRTO（目標復旧時間）・RPO（目標復旧時点）・RLO（目標復旧レベル）を挙げ、「RTOとRLOとを定めた例」を選ばせる問題です（応用情報技術者試験令和6年度秋期午前問55と同一問題）。正解（エ）は「サービスの中断から1日以内に、中断したサービスのうちの重要なサービスに限定してサービスを復旧する」です。

この問題のポイントは、1つの選択肢の中に複数の指標が混在している点です。「中断から◯時間以内」はRTO、「◯時点のデータまで復旧」はRPO、「重要サービスに限定して復旧」はRLOと、フレーズごとに指標を切り分ける訓練が有効です。用語の丸暗記ではなく、具体例を指標に結びつける力が問われます。

科目B（旧午後）に向けて：事例文からBCPとDRのつながりを読み解く

科目B（旧午後）の事例を読む練習では、目標値とバックアップ・待機方式が整合するかを確認しましょう。事例を読むときは、次の2つの視点で整理すると、BCPとDRのつながりが見えやすくなります。

BCPの視点：業務停止の影響から許容できる停止時間（MTPD）を見極め、復旧の優先順位とRTO・RPOを決める
DRの視点：その目標を満たすバックアップ方式や待機方式、バックアップサイト（ホット／ウォーム／コールド）を選ぶ

「BCPで決めた目標を、DRという技術手段で実現できているか」を確かめる視点を持っておくと、事例の設定と設問のつながりを読み取りやすくなります。

問われやすい論点と関連キーワード

包含関係の逆転：「BCPはDRの一部」とする選択肢（正しくはDRがBCPの一部）
RPOとRTOの取り違え：時間の長さ（RTO）とデータの時点（RPO）を入れ替える
RTOとMTPDの大小関係：RTO < MTPD を逆に提示する
サイト区分（拠点の準備度）とスタンバイ方式（待機系の稼働状態）の混同
関連規格・ガイドライン：ISO 22301:2019（事業継続マネジメントシステム：BCMS）とJIS Q 22301:2020、内閣府「事業継続ガイドライン」、BIA（ビジネスインパクト分析）などの用語

【演習】BCPとDRの違い理解度チェック（全10問）

BCP/DR分野は、科目A-1（旧午前I）では復旧指標の定義・分類が問われた例があり（令和6年度秋期高度共通午前I 問20）。科目B（旧午後）の事例を読む練習では、目標値とバックアップ・待機方式が整合するかを確認しましょう。混同しやすいのは「BCPとDRの包含関係の逆転」「RPOとRTOの取り違え」「RTOとMTPDの大小関係」の3点です。以下の練習問題で本記事の理解度を確認してみましょう。

【練習問題】BCPとDRの違い（全10問）