【徹底解説】RPOとRTOの違いとは？システムを救うバックアップ戦略の決定版

システム運用において、情報セキュリティの3要素（機密性・完全性・可用性）のうち、見落とされがちながら極めて重要なのが「可用性」の確保です。どれほど堅牢なファイアウォールを設置しても、自然災害やハードウェア障害、ランサムウェアによるデータ暗号化が発生すれば、システムは停止します。

その時、企業の命運を分けるのがバックアップ戦略です。「バックアップは取っているから大丈夫」と考えている現場ほど、いざ復旧しようとした時に「データが1週間前まで戻ってしまった」「復旧に3日かかりビジネスが止まった」という悲劇に見舞われます。

本記事では、バックアップ戦略の核となる指標「RPO（目標復旧時点）」と「RTO（目標復旧時間）」を深く理解し、コストとリスクのバランスが取れた最適なバックアップ設計を行うための知識を体系的に解説します。単なる用語の暗記ではなく、実務で使える設計思想を身につけましょう。

RPOとRTO：事業継続を支える2つの重要指標

バックアップやディザスタリカバリ（DR：災害復旧）を計画する際、決して避けて通れないのがRPOとRTOという2つの指標です。これらは「いつまで」「どれくらい」という時間の概念を定義するものであり、経営判断にも直結する重要な要素となります。

障害発生時のタイムラインを可視化する

障害が発生した瞬間を「0地点」として、時間を過去と未来に分けて考えます。

• 過去へ遡る視点：どの時点のデータまで救えるか？
• 未来へ進む視点：いつ業務を再開できるか？

この2つの視点を定量化したものがRPOとRTOです。これらをあいまいにしたままシステムを構築することは、ゴールのないマラソンを走るようなものであり、非常に危険です。

次の図は、目標どおりに復旧できた場合の例です。RPO・RTOは実際の結果ではなく、あらかじめ定めておく目標値である点に注意してください。

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

RPOは、「障害発生時から過去に遡って、どの時点までのデータを復旧させるか」という目標値です。これは言い換えれば、「最大でどれだけのデータ損失を許容できるか」という指標になります。

RPOを「24時間」に設定した場合を考えてみましょう。これは「毎日深夜0時にバックアップを取る」運用などが該当します。もし0時のバックアップ取得後、その日の23時に障害が発生した場合、直前のバックアップ（23時間前）以降のデータ（約23時間分）は失われます。この23時間分のデータ損失がビジネス上許容できるのであれば、RPO＝24時間は適切な設定です。

しかし、銀行の勘定系システムや証券取引システムのように、数秒のデータ損失も許されない場合、RPOは「0秒（または限りなく0に近い値）」を目指す必要があります。これを実現するには、リアルタイムのデータレプリケーション（同期）などの高度な技術が必要となります。

RPO設定による影響

• RPOが短い（0に近い）：データ損失は少ないが、高頻度なバックアップや同期が必要となり、システム負荷やコストが増大する
• RPOが長い：データ損失のリスクは高まるが、バックアップ運用は楽になり、コストも抑えられる

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

RTOは、「障害発生時から未来に向かって、いつまでにシステムを復旧させ、業務を再開させるか」という目標値です。これは「最大でどれだけの業務停止時間（ダウンタイム）を許容できるか」を示します。

ECサイトにおいてRTOを「1時間」と設定した場合、障害発生から1時間以内にはサイトを再開し、注文を受け付けられる状態に戻す必要があります。これには、故障したサーバーの切り替え、OSの起動、データのリストア、アプリケーションの動作確認など、すべての復旧プロセスが含まれます。

RTOを短くするためには、予備機を常に稼働させておく（ホットスタンバイ）や、自動切り替え（フェイルオーバー）の仕組みが必要です。逆に、RTOが「3日」で良いのであれば、代替機を倉庫から出してきてセットアップし、テープからデータを戻すといった手動対応でも間に合うかもしれません。

RTO設定による影響

• RTOが短い（0に近い）：業務停止時間は短いが、待機系システムの維持費や自動化のコストが跳ね上がる
• RTOが長い：業務への影響（機会損失）は大きくなるが、復旧設備への投資は抑えられる

RLO（目標復旧レベル）とMTPD（最大許容停止時間）

RPO・RTOとあわせて押さえておきたいのがRLO（Recovery Level Objective：目標復旧レベル）です。RLOは「どの水準まで業務・サービスを復旧させるか」という目標値で、たとえば「重要なサービスに限定して再開する」「通常の50%の処理能力で再開する」といった形で定めます。障害直後から全機能を元に戻すのではなく、まず重要な業務を優先して再開するという考え方です。

もう1つの関連指標がMTPD（Maximum Tolerable Period of Disruption：最大許容停止時間）です。MTPDは、業務が止まったままだと事業の存続に深刻な影響が出る限界の時間で、BIAで見極めます。RTOはこのMTPDより短く設定します。RTOをMTPDぎりぎりにすると、復旧が少し遅れただけで限界を超えてしまうためです。

• RPO：どの時点のデータまで戻すか
• RTO：いつまでに復旧させるか（MTPDより短く設定する）
• RLO：どの水準まで復旧させるか

コストとリスクのトレードオフを理解する

RPOとRTOは、短ければ短いほど良いのは当然です。誰だってデータは失いたくないですし、システムはすぐに復旧してほしいと考えます。しかし、ここには「コスト」という大きな壁が存在します。

復旧レベルと投資額の相関関係

RPO/RTOの目標を厳しく（短く）するほど、追加投資や運用負荷が増える傾向があります。必要な構成やコストは、既存環境や対象の規模によって異なります。以下に、代表的な構成と特徴を示します（RPO・RTOの値は構成例ごとの目安で、実際の値は構成によって変わります）。

1. テープバックアップ／コールドスタンバイ

• コスト：低
• RPO：1日～数日（バックアップ頻度による）
• RTO：数日～数週間（ハードウェア調達や物理搬送が必要な場合も）
• 適用例：アーカイブデータ、緊急性の低い社内システム

2. ディスクバックアップ／ウォームスタンバイ

• コスト：中
• RPO：数時間～1日
• RTO：数時間～1日
• 適用例：一般的なファイルサーバー、Webサーバー

3. リアルタイムレプリケーション／ホットスタンバイ・クラスタ構成

• コスト：高（本番機と同等の設備がもう1セット必要）
• RPO：ほぼ0
• RTO：数分～数秒
• 適用例：基幹業務システム、金融システム、高負荷ECサイト

最適なRPO/RTOは、対策コストと損失コストを合計した総コストが最も小さくなる点です。2本の曲線が交わる点が最適になるとは限らない点に注意してください。

経営判断としてのBIA（ビジネスインパクト分析）

適切なRPO/RTOを決定するためには、システム管理者の独断ではなく、経営層を巻き込んだ「ビジネスインパクト分析（BIA）」が不可欠です。

BIAで検討すべき主な項目は以下の通りです。

• システムが止まることで、1時間あたりいくらの損失が出るか？
• どのデータが消失すると、法律違反や社会的信用の失墜につながるか？
• 手作業での代替運用は可能か？その限界は何日か？
• 顧客や取引先への影響はどの程度か？

これらの問いに対する答えをもとに、「これ以上の投資は過剰である」「これ以下の対策では会社が潰れる」というラインを見極めるのが、真のバックアップ戦略です。セキュリティエンジニアとしては、この判断材料を技術的な観点から提示する能力が求められます。

バックアップ方式の種類とRPO/RTOへの影響

RPOとRTOの目標が決まったら、それを実現するための具体的なバックアップ方式を選定します。基本となる3つの方式（フル、差分、増分）の違いを、復旧速度（RTO）の観点から整理しましょう。

1. フルバックアップ（Full Backup）

対象となるすべてのデータを毎回丸ごとバックアップする方式です。

メリット

• 復旧（リストア）が最も簡単で速い
• 最後のフルバックアップ・データを戻すだけで完了するため、手順がシンプルでミスが起きにくい

デメリット

• バックアップに時間がかかる
• データ容量が大きいため、ストレージコストがかさむ

RTOへの影響

リストア作業自体は早いため、RTO短縮に寄与します。しかし、バックアップウィンドウ（バックアップにかかる時間）が長くなるため、頻繁に行うのが難しく、結果としてRPOが長くなりがちです（例：週1回など）。

2. 差分バックアップ（Differential Backup）

前回の「フルバックアップ」から、変更があった部分のみをバックアップする方式です。

仕組み

日曜にフルバックアップを取り、月曜は「日曜からの変更分」、火曜は「日曜からの変更分（月曜分含む）」を保存します。日を追うごとにバックアップ容量は増えていきます。

メリット

• フルバックアップよりは短時間で済む
• 復旧手順が比較的シンプル

復旧手順

「最新のフルバックアップ」＋「戻したい時点の差分バックアップ（1つ）」の計2回のデータ適用で復旧可能です。

RTOへの影響

増分バックアップに比べてリストア回数が少ないため、比較的RTOを短く保てるバランスの良い方式です。

3. 増分バックアップ（Incremental Backup）

前回のバックアップ（フル、または増分）から、変更があった部分のみをバックアップする方式です。

仕組み

日曜にフルバックアップ。月曜は「月曜の変更分」、火曜は「火曜の変更分」のみを保存します。バックアップ容量と時間は最小で済みます。

メリット

• バックアップ時間が最も短い
• ネットワーク負荷も低い
• 頻繁にバックアップできるため、RPOを短く設定しやすい

復旧手順

「最新のフルバックアップ」＋「月曜分」＋「火曜分」＋「水曜分」…というように、障害発生時点までの全ての増分データを順番に適用する必要があります。

RTOへの影響

リストア手順が複雑で時間がかかるため、RTOは長くなる傾向があります。また、途中の増分データが1つでも破損していると、それ以降の復旧ができなくなるリスクがあります。

世代管理（ローテーション）の重要性

「最新のバックアップがあれば良い」というのは間違いです。なぜなら、ウイルス感染やファイル破損に気づかずにバックアップを取ってしまうと、バックアップデータ自体も汚染されているからです。これでは復旧できません。

そこで重要になるのが「世代管理」です。典型的な手法としてGFS（Grandfather-Father-Son）ローテーションがあります。

GFSローテーションの構成

• 息子（Son / 日次）：直近のデータを復旧（増分／差分など）。4日〜1週間分保持
• 父（Father / 週次）：週末ごとのフルバックアップ。4〜5週間分保持
• 祖父（Grandfather / 月次）：月末のフルバックアップ。1年〜数年分保持

この方式により、「昨日のデータ」だけでなく「半年前のデータ」が必要になった場合にも対応できます。特にランサムウェア等の潜伏期間が長い脅威に対しても、感染前のクリーンな状態に戻せる可能性が高まります（どの時点まで戻すかという復旧時点（リカバリポイント）の選択肢が増えることになります）。

現代の脅威に対抗する「3-2-1ルール」と不変性

バックアップを取っていても、バックアップサーバーごと災害に遭ったり、バックアップデータも同時にランサムウェアに暗号化されたりしては意味がありません。現代のセキュリティ基準では、物理的な隔離と論理的な保護が必須です。

3-2-1ルール：バックアップの黄金律

米国の写真家ピーター・クローグが提唱し、US-CERT（米国コンピュータ緊急事態対応チーム。2023年2月にCISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）へ統合）も推奨していた、バックアップの黄金律です。

3-2-1ルールの内容

1. 3つのデータコピーを持つ：本番データ1つ ＋ バックアップ2つ
2. 2種類の異なる媒体に保存する：例：ディスクとテープ、ディスクとクラウドのオブジェクトストレージなど。同じ種類の媒体だけだと、同じ原因で同時に故障・破損するリスクがあるため
3. 1つは遠隔地（オフサイト）に保管する：例：遠隔地の支店、クラウドストレージ。これにより、拠点ごとの火災や地震による全損を防ぐ

このルールを守ることで、バックアップの単一障害点（Single Point of Failure）を排除し、多くの災害シナリオに対する耐性を高められます。ただし、オフサイトのコピーもネットワーク経由で書き換えられる状態だとランサムウェアには破壊されうるため、次に述べる不変性（イミュータブル）やオフライン保管と組み合わせることが重要です。

ランサムウェア対策の切り札：イミュータブルバックアップ

近年、特に重要視されているのがImmutable（不変）バックアップです。高度なランサムウェア攻撃の中には、本番データを暗号化する前にバックアップデータを破壊・暗号化し、復旧の道を断とうとするものがあります。

これに対抗するため、保存したデータを保持期間中の変更・削除から保護する機能（WORM：Write Once Read Many）を持つストレージにバックアップを保存します。管理者が保護を解除・短縮できるかどうかは、製品・モード・ロック状態によって異なります。

イミュータブルバックアップの実現方法

• AWS S3のObject Lock機能：保護の単位はオブジェクトのバージョンで、保護されたバージョンの上書き・恒久削除を防ぐ（同じキーへの新しいバージョンや削除マーカーの作成は可能）。コンプライアンスモードはrootユーザーを含め保持期間中に解除・短縮できないが、ガバナンスモードは特別な権限を持つユーザーなら解除できる
• Azure Blob StorageのImmutable Storage：時間ベースの保持ポリシーは、ロック済みなら保持期間の短縮や削除ができないが、未ロックの間も対象データの上書き・削除は防ぐ。ただし、権限を持つ利用者は保持ポリシー自体を短縮・削除できる
• LTOテープのWORMカートリッジ
• 専用バックアップアプライアンス

ここで、イミュータブル（不変性）と論理的なエアギャップ（隔離）は別の概念として区別しておきましょう。イミュータブルは「保存したデータを保持期間中は変更・削除させない」というデータ側の性質です。一方、論理的なエアギャップは、バックアップ環境を本番環境のネットワークや認証基盤から切り離し（別アカウント・別の認証情報・通常時は通信経路を閉じるなど）、攻撃者がそもそも到達しにくくする隔離の考え方です。なお、通常の書き換え可能なテープをオフライン保管するのは、不変性ではなく隔離（物理的なエアギャップ）の対策です。両者を組み合わせることで、ランサムウェアから復旧手段を残すうえで有力な対策になります。保護期間中のバックアップデータは削除できないため、攻撃者が管理者権限を奪取しても復旧できる可能性を大きく高められます（ただし、特権で解除できる設定（例：S3 Object Lockのガバナンスモード、Azureの未ロックの保持ポリシー）の場合や、感染後のデータをバックアップしている場合は守り切れないため、設定と世代管理の確認が欠かせません）。

BCP（事業継続計画）におけるシステム構成

RTO（復旧時間）を劇的に短縮するためには、データだけでなく、システムそのものの予備（待機系システム）を用意する必要があります。ここで「ホット・ウォーム・コールド」という言葉は、2つの別の軸で使われる点に注意してください。1つは待機系の稼働状態を表すスタンバイ方式（ホットスタンバイ・ウォームスタンバイ・コールドスタンバイ）、もう1つは遠隔地に設けるディザスタリカバリ（DR）サイトの拠点としての準備度を表すサイト区分（ホットサイト・ウォームサイト・コールドサイト）です。まずスタンバイ方式を3段階で整理し、DRサイトの区分は最後にまとめます。

1. コールドスタンバイ（Cold Standby）

概要

予備機を用意しておくものの、電源を落とした状態（またはOS・アプリが未導入の状態）で待機させておく方式。障害発生時に電源を入れ、必要に応じてOSやアプリの導入を行い、データをリストアします。

特徴

• コスト：最も安い
• RPO：バックアップ頻度による（通常1日～数日）
• RTO：長い（数日〜数週間）
• 適性：停止しても大きな損害が出ないシステム、アーカイブシステム

2. ウォームスタンバイ（Warm Standby）

概要

本記事では、予備機にOSやアプリまでは導入して起動しておき、切替時に最新のバックアップデータの適用などを行ってから本番稼働させる構成例として説明します。なお、製品・構成によっては、縮小した規模の待機環境へ継続的にデータを複製しておく構成もウォームスタンバイと呼ばれます。

特徴

• コスト：中程度
• RPO：数時間～1日（上記の構成例での目安）
• RTO：中程度（上記の構成例での目安は数時間〜1日。実際の所要時間は構成による）
• 適性：一定のダウンタイムは許容できるが、セットアップの手間は省きたいシステム

3. ホットスタンバイ（Hot Standby）

概要

本番機とまったく同じ構成の予備機を常時稼働させ、データもリアルタイムで同期（レプリケーション）させておく方式。障害発生時は自動的に予備機へ切り替わります。

特徴

• コスト：最も高い（2倍以上のリソースが必要）
• RPO：ほぼ0（リアルタイム同期）
• RTO：極めて短い（数秒〜数分）
• 適性：止まることが許されないミッションクリティカルなシステム（金融、医療、EC等）

ただし、レプリケーションやリアルタイム同期は、誤操作による削除や論理破損、ランサムウェアによる暗号化もそのまま待機系へ複製します。ホットスタンバイはハードウェア障害などからの切替には強いものの、過去の時点に戻せるバックアップ（世代管理）の代わりにはなりません。

DRサイトのホットサイト・ウォームサイト・コールドサイト

遠隔地のDRサイトは、拠点としてどこまで準備されているかで次のように区分されます。

• ホットサイト：機器・ネットワーク・データが整っており、短時間で業務を切り替えられる拠点
• ウォームサイト：機器や回線は用意されているが、最新データの投入や設定作業が必要な拠点
• コールドサイト：電源・空調・回線引き込みなどの場所（設備）だけを確保し、機器は被災後に搬入・設置する拠点

スタンバイ方式が「待機系がどこまで動いているか」を表すのに対し、サイト区分は「拠点の設備がどこまで整っているか」を表します。たとえば「コールドスタンバイ」は予備機が手元にある状態を指すのに対し、「コールドサイト」は機器すら置かれていない状態を指すことがあり、両者は同じ意味ではありません。

情報処理安全確保支援士試験や実務の現場では、対象システムの重要度（SLA：サービスレベル合意書など）に基づき、これらの方式を適切に使い分ける提案力が問われます。

多くの現場が見落とす「リストアテスト」の重要性

最後に、最も重要でありながら最も軽視されがちなポイントをお伝えします。それは「リストア（復元）テスト」を行っているか？という点です。

シュレーディンガーのバックアップ

バックアップ処理のログが「成功」になっていても、実は中身が空だったり、パスワードがわからなくなっていたり、復旧手順書が古くて役に立たなかったりすることは日常茶飯事です。「バックアップは成功していたが、リストアには失敗した」という事例は枚挙に暇がありません。

量子力学のシュレーディンガーの猫になぞらえて、「シュレーディンガーのバックアップ」という表現があります。これは「リストアを試みるまで、そのバックアップが有効か無効かは確定しない」という皮肉を込めた言葉です。

リストアテストの実施方法

定期的に、実際にバックアップデータを使ってシステムを復旧させる訓練を行ってください（計画の一例：少なくとも年に1回、できれば半期に1回）。

リストアテストで確認すべき項目

• バックアップデータの整合性（破損していないか）
• 復旧手順書の正確性（手順通りに復旧できるか）
• 復旧にかかる実際の時間（目標値であるRTOとの差）
• 必要な権限やパスワードへのアクセス
• 復旧後のアプリケーション動作確認
• チーム内での役割分担と連携

この訓練により、実際の復旧所要時間を計測し、目標値であるRTOとの差を評価できます。差があれば、それを埋めるための改善につなげられます。また、手順書の不備や想定外の問題を事前に発見できるため、本番の障害時にパニックにならずに済みます。

リストアテストの頻度と範囲

システムの重要度に応じて、リストアテストの頻度と範囲を調整します。以下は計画の一例です。実際の頻度は、重要度、変更の頻度、規制・契約上の要求、復旧目標に応じて決めます。

• ミッションクリティカルなシステム：四半期に1回、本番同等の環境で全体テスト
• 重要なシステム：半年に1回、主要機能のテスト
• 一般的なシステム：年1回、サンプルデータでのテスト

テスト結果は必ず記録し、改善点を次回のバックアップ計画に反映させることが重要です。

バックアップ戦略の設計手順：実践編

ここまで学んだ知識を実際のバックアップ戦略設計に活かすための、具体的な手順を示します。

ステップ1：システムの分類と優先順位付け

まず、組織内のすべてのシステムを洗い出し、ビジネスへの影響度に応じて分類します。

システム分類の例

• クラス1（ミッションクリティカル）：基幹業務システム、決済システム、顧客データベース
• クラス2（重要）：営業支援システム、在庫管理システム、社内ポータル
• クラス3（一般）：アーカイブデータ、テスト環境、個人用ファイルサーバー

ステップ2：各クラスのRPO/RTO目標を設定

ビジネス部門と協議し、各クラスに適切なRPO/RTOを設定します。

設定例

• クラス1：RPO = 1時間、RTO = 2時間
• クラス2：RPO = 4時間、RTO = 8時間
• クラス3：RPO = 1日、RTO = 3日

ステップ3：バックアップ方式と待機系の選定

設定したRPO/RTOを満たすための技術方式を選定します。

クラス1の場合

• ホットスタンバイ構成
• リアルタイムレプリケーション
• 自動フェイルオーバー
• 1時間ごとの増分バックアップ

クラス2の場合

• ウォームスタンバイ構成
• 4時間ごとの増分バックアップ
• 週1回のフルバックアップ

クラス3の場合

• コールドスタンバイ（または待機系なし）
• 日次のフルバックアップ
• テープへの週次アーカイブ

ステップ4：3-2-1ルールの適用

すべてのクラスに対して、3-2-1ルールを適用します。

• オンサイトのディスクバックアップ
• オフサイトのクラウドバックアップ
• 重要データは月次でテープにアーカイブ

ステップ5：運用手順とテスト計画の策定

バックアップの実施手順、リストア手順、定期テスト計画を文書化します。

必要な文書

• バックアップ運用手順書
• リストア手順書（システム別）
• 障害対応フローチャート
• テスト計画書
• 連絡体制図

ステップ6：定期的な見直しと改善

年に1回以上、バックアップ戦略全体を見直し、ビジネス環境の変化やテスト結果を反映させます。

RPO/RTO設定の例：業種別の考え方

業種別に、RPO/RTO設定の一例（目安）を紹介します。実際の値は各組織のBIAの結果によって大きく異なります。

金融機関（銀行・証券）

システム特性

取引の正確性とリアルタイム性が最重要。数秒のデータ損失も許されない。

RPO/RTO設定

• 勘定系システム（センター内の機器障害）：RPO = 0、RTO = 数秒〜数分程度を目指す（同一サイト内の冗長構成と自動切替）
• 勘定系システム（広域災害でメインセンターが被災）：遠隔地のバックアップセンターへ切り替える。RPOはほぼ0〜数分、RTOは数時間程度を目標とする例がある
• 情報系システム：RPO = 15分、RTO = 1時間

採用技術

• サイト内のクラスタ構成・自動フェイルオーバー
• 遠隔地のバックアップセンターへのレプリケーション（同期レプリケーションは書き込みのたびに遠隔地の応答を待つため、距離が延びるほど遅延で性能が落ちる。遠距離では非同期レプリケーションを使い、わずかなデータ損失を許容する設計もある）
• アクティブ-アクティブ構成
• 金融庁の監督指針（システムリスク管理）やFISC（金融情報システムセンター）の安全対策基準を踏まえた設計

EC・小売業

システム特性

営業時間中のダウンタイムは直接売上損失につながる。ピーク時間帯は特に重要。

RPO/RTO設定

• ECサイト本体：RPO = 5分、RTO = 15分
• 在庫管理システム：RPO = 1時間、RTO = 2時間
• 顧客データベース：RPO = 15分、RTO = 30分

採用技術

• クラウドベースの自動スケーリングとフェイルオーバー
• CDNによる負荷分散
• データベースのレプリケーションと、トランザクションログの数分間隔での転送（RPO 5分・15分を満たすため）
• 日次のフルバックアップと世代管理（レプリケーションでは防げない論理破損やランサムウェアに備えるため）

製造業

システム特性

生産ラインの停止は大きな損失だが、完全なリアルタイム性は不要。

RPO/RTO設定

• 生産管理システム：RPO = 1時間、RTO = 4時間
• 設計データ（CAD）：RPO = 4時間、RTO = 1日
• 経理システム：RPO = 1日、RTO = 2日

採用技術

• ウォームスタンバイ構成
• 1時間ごとの増分バックアップ
• 週次のフルバックアップをオフサイト保管

医療機関

システム特性

患者の生命に関わるため、電子カルテの可用性は極めて重要。

RPO/RTO設定

• 電子カルテシステム：RPO = 0秒、RTO = 5分
• 医療機器連携システム：RPO = 1分、RTO = 10分
• 予約システム：RPO = 1時間、RTO = 2時間

採用技術

• リアルタイム同期のホットスタンバイ
• 厚生労働省「医療情報システムの安全管理に関するガイドライン」第7.0版（令和8年6月）を踏まえた設計（同ガイドラインはRPO/RTOの具体的な数値を定めていないため、目標値は各医療機関がBCPの中で決める）
• 災害拠点としての遠隔地DRサイト

コスト最適化のテクニック

RPO/RTOを満たしながらコストを抑えるための実践的なテクニックを紹介します。

階層化バックアップ戦略

すべてのデータを同じレベルで保護する必要はありません。データの重要度に応じて階層化します。

Tier 1（最重要データ）

• リアルタイム同期
• ホットスタンバイ
• 例：顧客取引データ、決済情報

Tier 2（重要データ）

• 1時間ごとのバックアップ
• ウォームスタンバイ
• 例：業務アプリケーションデータ

Tier 3（一般データ）

• 日次バックアップ
• テープアーカイブ
• 例：過去の記録、ログファイル

クラウドとオンプレミスのハイブリッド活用

初期投資を抑えつつ、柔軟性を確保できるハイブリッド構成が注目されています。

コスト削減のポイント

• 日次バックアップはオンプレミス（高速・低コスト）
• 長期保管とDRサイトはクラウド（拡張性・災害対策）
• 使用量に応じた従量課金で無駄を削減

重複排除と圧縮技術の活用

バックアップデータの容量を削減することで、ストレージコストと転送時間を大幅に削減できます。

導入効果

• 重複排除により、仮想マシンイメージや世代バックアップなど重複の多いデータでは大幅な容量削減が期待できる（削減率はデータの種類・世代数に大きく依存する）
• 圧縮によるさらなる削減（暗号化済み・圧縮済みデータでは効果が小さい）
• ネットワーク帯域の節約

オープンソースツールの活用

商用製品に比べて大幅にコストを削減できるオープンソースのバックアップツールも選択肢です。

代表的なツール

• Bacula：エンタープライズグレードのバックアップソフトウェア
• Amanda：ネットワークバックアップソリューション
• Duplicati：クラウド対応のバックアップツール
• Restic：高速で安全なバックアッププログラム

ただし、サポート体制や運用負荷を考慮し、TCO（Total Cost of Ownership：総所有コスト）で判断することが重要です。

ランサムウェア時代のバックアップ戦略

近年急増しているランサムウェア攻撃に対抗するための、特化した対策を紹介します。

ランサムウェアの攻撃パターン

現代のランサムウェア攻撃の典型的な流れの一例を示します。工程の有無や順序は攻撃によって異なり、暗号化をせずに、窃取したデータの公開だけを材料に脅迫するケースもあります。

1. システムへの侵入（フィッシング、脆弱性攻撃等）
2. 権限昇格と横展開
3. データの窃取（外部への持ち出し）
4. バックアップシステムの特定と破壊
5. データの暗号化
6. 身代金要求（暗号化の解除と、窃取したデータを公開しないことの両方を材料にする二重恐喝）

このうち「バックアップ破壊」が加わったことで、従来の対策では不十分になっています。また、データの窃取に対しては、バックアップは役に立ちません。バックアップは暗号化されたデータを元に戻す手段であり、持ち出された情報の公開（情報漏えい）は防げないためです。漏えいへの対策は、アクセス制御、データの暗号化と鍵・復号権限の分離（暗号化していても、復号できる権限を奪われれば持ち出したデータを読まれてしまうため）、外部への持ち出しの検知など、バックアップとは別に講じる必要があります。

ランサムウェア対策のベストプラクティス

1. エアギャップバックアップ

ネットワークから切り離された（通常時は接続されない）バックアップを保持します。

• 定期的にオフライン化するテープ（物理的なエアギャップ）
• バックアップ時以外はネットワーク接続を遮断できる専用アプライアンス（論理的なエアギャップ）

2. イミュータブル（不変）設定の徹底

一度書き込んだら削除・変更できない設定を有効化します。

• 保護期間を設定する（例：30日間。ランサムウェアの潜伏期間や世代管理の方針に合わせて決める）
• S3のコンプライアンスモードやAzureのロック済みポリシー等では管理者権限でも保護期間中は削除できない（S3 Object Lockのガバナンスモードのように特別な権限で解除できるモードもあるため、モードの選択と権限管理を確認する）
• 改ざん検知機能

3. 多要素認証（MFA）の導入

バックアップシステムへのアクセスには必ず多要素認証を要求します。

4. ゼロトラストアーキテクチャ

「すべてを疑う」設計思想で、バックアップシステムを保護します。

• 最小権限の原則
• ネットワークセグメンテーション
• 継続的な監視とログ分析

5. 定期的な侵入テスト

ペネトレーションテストでバックアップシステムの脆弱性を評価します。

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

RPO・RTOとバックアップは、科目A-1（旧午前I）では用語の定義、科目A-2（旧午前II）ではバックアップからの回復方法などを問う4択として、科目B（旧午後）ではインシデント対応や事業継続の事例の中で復旧の考え方を問う形で登場します。ここでは、IPAの公開問題で確認できる過去問と、問われ方の傾向を整理します。

科目A-1（旧午前I）の過去問で確認する

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

サービスを復旧させるときの目標を定める指標としてRTO（目標復旧時間）・RPO（目標復旧時点）・RLO（目標復旧レベル）を挙げ、「RTOとRLOとを定めた例」を選ばせる問題です。正解（エ）は「サービスの中断から1日以内に、中断したサービスのうちの重要なサービスに限定してサービスを復旧する」で、「1日以内」がRTO、「重要なサービスに限定して」がRLOに当たります。「中断する何時間前の時点の状態にデータを復旧する」という記述はRPOを表すため、RPOを含む選択肢を正しく除外できるかがポイントです。

科目A-2・科目Bでの問われ方

科目A-2（旧午前II）では、バックアップからの回復方法が問われています。たとえば令和3年度春期 SC 午前II 問24は、ディスク障害時に、フルバックアップを取得してあるテープからディスクにデータを復元した後、フルバックアップ取得時以降の更新後コピーをログから反映させてデータベースを回復する方法を選ぶ問題で、正解は（エ）ロールフォワードです。更新前コピーを使って更新を取り消すロールバックとの取り違えに注意しましょう。科目B（旧午後）では、ランサムウェア被害などの事例の中で、バックアップをどこにどう保管すべきか（ネットワークからの隔離、世代管理など）や、復旧までの手順を記述させる形で問われることがあります。

定番のひっかけポイント

• RPO（どの時点のデータまで戻すか）とRTO（いつまでに復旧するか）の向きの取り違え
• 差分バックアップ（フル＋最新の差分）と増分バックアップ（フル＋すべての増分）のリストア手順の混同
• 「レプリケーションがあればバックアップは不要」という誤解（論理破損や暗号化も複製される）
• スタンバイ方式（待機系の稼働状態）とDRサイトの区分（拠点の準備度）の混同

【演習】RPO/RTOとバックアップ戦略 理解度チェック（全10問）

RPO・RTOとバックアップは、科目A-1（旧午前I）では用語の定義、科目A-2（旧午前II）ではバックアップからの回復方法などを問う4択として、科目B（旧午後）ではランサムウェア被害などの事例の中でバックアップの保管方法や復旧の考え方を記述させる形で問われます。定番のひっかけは、RPO（どの時点のデータまで戻すか）とRTO（いつまでに復旧するか）の取り違え、差分と増分でリストアに必要なデータの混同、レプリケーションがあればバックアップは不要という誤解です。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：バックアップは「保険」ではなく「戦略」である

バックアップは、単なるデータのコピー作業ではありません。RPOとRTOという2つの軸を中心に、ビジネスの継続性を担保するための高度な戦略です。

本記事の重要ポイント

1. RPOとRTOの正確な理解

• RPO（どの時点まで戻すか）：データ損失の許容範囲
• RTO（いつまでに戻すか）：業務停止の許容時間
• 両者は独立した指標であり、それぞれ最適化が必要

2. コストとリスクのバランス

• RPO/RTOの目標を厳しくするほど追加投資・運用負荷が増える傾向
• ビジネスインパクト分析（BIA）による適切な目標設定
• 経営層を巻き込んだ合意形成が不可欠

3. バックアップ方式の使い分け

• フルバックアップ：復旧は速いがRPOが長くなりがち
• 差分バックアップ：バランス型、実用的な選択肢
• 増分バックアップ：頻繁に取得できRPOを短くしやすいが、RTOが長くなる
• GFS世代管理で長期的なデータ保護を実現

4. 3-2-1ルールと不変性

• 3つのコピー、2種類の媒体、1つはオフサイト
• イミュータブルバックアップでランサムウェア対策
• 物理的・論理的なエアギャップの確保

5. システム構成の段階的選択

• コールドスタンバイ：低コスト・長RTO
• ウォームスタンバイ：中コスト・中RTO
• ホットスタンバイ：高コスト・短RTO

6. リストアテストの徹底

• 「シュレーディンガーのバックアップ」を避ける
• 重要度などに応じて計画した定期的な実地訓練（例：年1回以上）
• 手順書の検証と想定RTOとの比較

実践へのステップ

前述の設計手順（ステップ1〜6）を確実に実行することで、あなたの組織は「想定外の事態」においても、冷静かつ迅速にビジネスを再生させることができるようになります。

情報処理安全確保支援士として、また実務担当者として、技術だけでなく「安心」を設計できるエンジニアを目指しましょう。バックアップ戦略は、障害や攻撃を受けた後に事業を立て直すための最後の砦です。その設計と運用に妥協は許されません。

今日から、自組織のバックアップ戦略を見直してみてください。RPOとRTOは明確に定義されていますか？リストアテストは実施していますか？3-2-1ルールは守られていますか？

これらの問いに自信を持って「Yes」と答えられる組織こそが、真に災害に強い、レジリエントな企業と言えるでしょう。

---

関連記事

BCP（事業継続計画）とDR（災害復旧）について、さらに組織論やガイドラインの観点から深掘りした記事はこちらです。データだけでなく、人やプロセスをどう守るか、という視点を学んでいきましょう。

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

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA「令和6年度 問題冊子・配点割合・解答例・採点講評」
• IPA「令和3年度春期 情報処理安全確保支援士試験 午前II 問題冊子」
• IPA「令和3年度春期 情報処理安全確保支援士試験 午前II 解答例」
• IPA「応用情報技術者試験、高度試験及び情報処理安全確保支援士試験のCBT方式による実施について」
• 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版（令和8年6月）」
• 内閣府「事業継続ガイドライン」
• NIST SP 800-34 Rev. 1「Contingency Planning Guide for Federal Information Systems」
• CISA「#StopRansomware Guide」
• AWS「Locking objects with Object Lock」（Amazon S3 ユーザーガイド）
• Microsoft「Overview of immutable storage for blob data」