システム運用において、セキュリティ対策と同様に極めて重要なのが「可用性」の確保です。どれほど堅牢なファイアウォールを設置しても、自然災害やハードウェア障害、ランサムウェアによるデータ暗号化が発生すれば、システムは停止します。
その時、企業の命運を分けるのがバックアップ戦略です。「バックアップは取っているから大丈夫」と考えている現場ほど、いざ復旧しようとした時に「データが1週間前まで戻ってしまった」「復旧に3日かかりビジネスが止まった」という悲劇に見舞われます。
本記事では、バックアップ戦略の核となる指標「RPO（目標復旧時点）」と「RTO（目標復旧時間）」を深く理解し、コストとリスクのバランスが取れた最適なバックアップ設計を行うための知識を体系的に解説します。単なる用語の暗記ではなく、実務で使える設計思想を身につけましょう。
RPOとRTO：事業継続を支える2つの重要指標
バックアップやディザスタリカバリ（DR：災害復旧）を計画する際、決して避けて通れないのがRPOとRTOという2つの指標です。これらは「いつまで」「どれくらい」という時間の概念を定義するものであり、経営判断にも直結する重要な要素となります。
障害発生時のタイムラインを可視化する
障害が発生した瞬間を「0地点」として、時間を過去と未来に分けて考えます。
- 過去へ遡る視点：どの時点のデータまで救えるか？
- 未来へ進む視点：いつ業務を再開できるか？
この2つの視点を定量化したものがRPOとRTOです。これらをあいまいにしたままシステムを構築することは、ゴールのないマラソンを走るようなものであり、非常に危険です。
RPO（Recovery Point Objective：目標復旧時点）とは
RPOは、「障害発生時から過去に遡って、どの時点までのデータを復旧させるか」という目標値です。これは言い換えれば、「最大でどれだけのデータ損失を許容できるか」という指標になります。
RPOを「24時間」に設定した場合を考えてみましょう。これは「毎日深夜0時にバックアップを取る」運用などが該当します。もし翌日の23時に障害が発生した場合、前日の深夜0時以降のデータ（約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が長い：業務への影響（機会損失）は大きくなるが、復旧設備への投資は抑えられる
コストとリスクのトレードオフを理解する
RPOとRTOは、短ければ短いほど良いのは当然です。誰だってデータは失いたくないですし、システムはすぐに復旧してほしいと考えます。しかし、ここには「コスト」という大きな壁が存在します。
復旧レベルと投資額の相関関係
RPO/RTOを極限まで短縮しようとすると、コストは指数関数的に増大します。以下に、代表的な構成と特徴を示します。
1. テープバックアップ／コールドスタンバイ
- コスト：低
- RPO：1日～数日（バックアップ頻度による）
- RTO：数日～数週間（ハードウェア調達や物理搬送が必要な場合も）
- 適用例：アーカイブデータ、緊急性の低い社内システム
2. ディスクバックアップ／ウォームスタンバイ
- コスト：中
- RPO：数時間～1日
- RTO：数時間～1日
- 適用例：一般的なファイルサーバー、Webサーバー
3. リアルタイムレプリケーション／ホットスタンバイ・クラスタ構成
- コスト：高（本番機と同等の設備がもう1セット必要）
- RPO：ほぼ0
- RTO：数分～数秒
- 適用例：基幹業務システム、金融システム、高負荷ECサイト
経営判断としての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年〜数年分保持
この方式により、「昨日のデータ」だけでなく「半年前のデータ」が必要になった場合にも対応できます。特にランサムウェア等の潜伏期間が長い脅威に対しても、感染前のクリーンな状態に戻せる可能性が高まります（RPOの観点では、どこまで過去に戻れるかの選択肢が増えることになります）。
現代の脅威に対抗する「3-2-1ルール」と不変性
バックアップを取っていても、バックアップサーバーごと災害に遭ったり、バックアップデータも同時にランサムウェアに暗号化されたりしては意味がありません。現代のセキュリティ基準では、物理的な隔離と論理的な保護が必須です。
3-2-1ルール：バックアップの黄金律
米国の写真家ピーター・クローグが提唱し、現在ではUS-CERT（米国コンピュータ緊急事態対策チーム）も推奨する、バックアップの黄金律です。
3-2-1ルールの内容
- 3つのデータコピーを持つ：本番データ1つ ＋ バックアップ2つ
- 2種類の異なる媒体に保存する：例：HDDとテープ、HDDとクラウド、NASと外付けディスクなど。同じ媒体だと、同時に故障するリスクがあるため
- 1つは遠隔地（オフサイト）に保管する：例：遠隔地の支店、クラウドストレージ。これにより、拠点ごとの火災や地震による全損を防ぐ
このルールを守ることで、単一障害点（Single Point of Failure）を排除し、あらゆる災害シナリオに対する耐性を確保できます。
ランサムウェア対策の切り札：イミュータブルバックアップ
近年、特に重要視されているのがImmutable（不変）バックアップです。高度なランサムウェアは、サーバーに侵入するとまずバックアップデータを破壊・暗号化し、復旧の道を断ってから本番データを攻撃します。
これに対抗するため、「一度書き込んだら、指定期間は管理者権限があっても変更・削除できない（WORM：Write Once Read Many）」機能を持つストレージにバックアップを保存します。
イミュータブルバックアップの実現方法
- AWS S3のObject Lock機能
- Azure Blob StorageのImmutable Storage
- LTOテープ（物理的WORM）
- 専用バックアップアプライアンス
この「論理的なエアギャップ」こそが、現在のセキュリティにおける最後の砦となります。たとえ攻撃者が管理者権限を奪取しても、保護期間中はバックアップデータを削除できないため、確実な復旧が可能になります。
BCP（事業継続計画）におけるシステム構成
RTO（復旧時間）を劇的に短縮するためには、データだけでなく、システムそのものの予備を用意する必要があります。これをディザスタリカバリ（DR）サイトと呼びます。待機系システムの準備レベルによって、3つの段階があります。
1. コールドスタンバイ（Cold Standby）
概要
予備のハードウェア場所だけを確保しておく、あるいは電源を落とした状態で保管しておく方式。障害発生時に電源を入れ、OSやアプリの導入、データのリストアを行います。
特徴
- コスト：最も安い
- RPO：バックアップ頻度による（通常1日～数日）
- RTO：長い（数日〜数週間）
- 適性：停止しても大きな損害が出ないシステム、アーカイブシステム
2. ウォームスタンバイ（Warm Standby）
概要
予備機にOSやアプリまでは導入し、電源を入れて立ち上げておくが、最新データは同期されていない状態。障害時に最新のバックアップデータを適用して本番稼働させます。
特徴
- コスト：中程度
- RPO：数時間～1日
- RTO：中程度（数時間〜半日）
- 適性：一定のダウンタイムは許容できるが、セットアップの手間は省きたいシステム
3. ホットスタンバイ（Hot Standby）
概要
本番機とまったく同じ構成の予備機を常時稼働させ、データもリアルタイムで同期（レプリケーション）させておく方式。障害発生時は自動的に予備機へ切り替わります。
特徴
- コスト：最も高い（2倍以上のリソースが必要）
- RPO：ほぼ0（リアルタイム同期）
- RTO：極めて短い（数秒〜数分）
- 適性：止まることが許されないミッションクリティカルなシステム（金融、医療、EC等）
情報処理安全確保支援士試験や実務の現場では、対象システムの重要度（SLA：サービスレベル合意書など）に基づき、これらの方式を適切に使い分ける提案力が問われます。
多くの現場が見落とす「リストアテスト」の重要性
最後に、最も重要でありながら最も軽視されがちなポイントをお伝えします。それは「リストア（復元）テスト」を行っているか？という点です。
シュレーディンガーのバックアップ
バックアップ処理のログが「成功」になっていても、実は中身が空だったり、パスワードがわからなくなっていたり、復旧手順書が古くて役に立たなかったりすることは日常茶飯事です。「バックアップは成功していたが、リストアには失敗した」という事例は枚挙に暇がありません。
量子力学のシュレーディンガーの猫になぞらえて、「シュレーディンガーのバックアップ」という表現があります。これは「リストアを試みるまで、そのバックアップが有効か無効かは確定しない」という皮肉を込めた言葉です。
リストアテストの実施方法
少なくとも年に1回、できれば半期に1回は、実際にバックアップデータを使ってシステムを復旧させる訓練を行ってください。
リストアテストで確認すべき項目
- バックアップデータの整合性（破損していないか）
- 復旧手順書の正確性（手順通りに復旧できるか）
- 復旧にかかる実際の時間（想定RTOとのギャップ）
- 必要な権限やパスワードへのアクセス
- 復旧後のアプリケーション動作確認
- チーム内での役割分担と連携
この訓練により、実際の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設定の実例を、業種別に紹介します。
金融機関（銀行・証券）
システム特性
取引の正確性とリアルタイム性が最重要。数秒のデータ損失も許されない。
RPO/RTO設定
- 勘定系システム：RPO = 0秒、RTO = 数秒（完全同期のホットスタンバイ）
- 情報系システム：RPO = 15分、RTO = 1時間
採用技術
- マルチサイトでの同期レプリケーション
- アクティブ-アクティブ構成
- 金融庁のシステムリスク管理基準に準拠
EC・小売業
システム特性
営業時間中のダウンタイムは直接売上損失につながる。ピーク時間帯は特に重要。
RPO/RTO設定
- ECサイト本体：RPO = 5分、RTO = 15分
- 在庫管理システム：RPO = 1時間、RTO = 2時間
- 顧客データベース：RPO = 15分、RTO = 30分
採用技術
- クラウドベースの自動スケーリングとフェイルオーバー
- CDNによる負荷分散
- 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時間
採用技術
- リアルタイム同期のホットスタンバイ
- 医療情報システムの安全管理に関するガイドライン準拠
- 災害拠点としての遠隔地DRサイト
コスト最適化のテクニック
RPO/RTOを満たしながらコストを抑えるための実践的なテクニックを紹介します。
階層化バックアップ戦略
すべてのデータを同じレベルで保護する必要はありません。データの重要度に応じて階層化します。
Tier 1（最重要データ）
- リアルタイム同期
- ホットスタンバイ
- 例：顧客取引データ、決済情報
Tier 2（重要データ）
- 1時間ごとのバックアップ
- ウォームスタンバイ
- 例：業務アプリケーションデータ
Tier 3（一般データ）
- 日次バックアップ
- テープアーカイブ
- 例：過去の記録、ログファイル
クラウドとオンプレミスのハイブリッド活用
初期投資を抑えつつ、柔軟性を確保できるハイブリッド構成が注目されています。
コスト削減のポイント
- 日次バックアップはオンプレミス（高速・低コスト）
- 長期保管とDRサイトはクラウド（拡張性・災害対策）
- 使用量に応じた従量課金で無駄を削減
重複排除と圧縮技術の活用
バックアップデータの容量を削減することで、ストレージコストと転送時間を大幅に削減できます。
導入効果
- 重複排除により70〜90%の容量削減が可能
- 圧縮により追加で30〜50%の削減
- ネットワーク帯域の節約
オープンソースツールの活用
商用製品に比べて大幅にコストを削減できるオープンソースのバックアップツールも選択肢です。
代表的なツール
- Bacula：エンタープライズグレードのバックアップソフトウェア
- Amanda：ネットワークバックアップソリューション
- Duplicati：クラウド対応のバックアップツール
- Restic：高速で安全なバックアッププログラム
ただし、サポート体制や運用負荷を考慮し、TCO（Total Cost of Ownership：総所有コスト）で判断することが重要です。
ランサムウェア時代のバックアップ戦略
近年急増しているランサムウェア攻撃に対抗するための、特化した対策を紹介します。
ランサムウェアの攻撃パターン
現代のランサムウェアは以下の手順で攻撃します。
- システムへの侵入（フィッシング、脆弱性攻撃等）
- 権限昇格と横展開
- バックアップシステムの特定と破壊
- データの暗号化
- 身代金要求
このうち、3番目の「バックアップ破壊」が追加されたことで、従来の対策では不十分になっています。
ランサムウェア対策のベストプラクティス
1. エアギャップバックアップ
物理的にネットワークから切り離されたバックアップを保持します。
- 定期的にオフライン化するテープ
- ネットワーク接続を制御できる専用アプライアンス
2. イミュータブル（不変）設定の徹底
一度書き込んだら削除・変更できない設定を有効化します。
- 最低でも30日間の保護期間
- 管理者権限でも削除不可
- 改ざん検知機能
3. 多要素認証（MFA）の導入
バックアップシステムへのアクセスには必ず多要素認証を要求します。
4. ゼロトラストアーキテクチャ
「すべてを疑う」設計思想で、バックアップシステムを保護します。
- 最小権限の原則
- ネットワークセグメンテーション
- 継続的な監視とログ分析
5. 定期的な侵入テスト
ペネトレーションテストでバックアップシステムの脆弱性を評価します。
【演習】RPO/RTOとバックアップ戦略 理解度チェック（全10問）
「バックアップは取っているから大丈夫」と考えていませんか？しかし、いざ障害が発生した際、「いつのデータまで戻せるのか（RPO）」「復旧に何時間かかるのか（RTO）」を正確に把握していなければ、ビジネスを守ることはできません。 本記事で解説したバックアップの基本用語から、ランサムウェア対策として必須のイミュータブルバックアップ、3-2-1ルールまで、重要ポイントを網羅した練習問題を作成しました。実務で通用する知識が身についているか、ぜひ確認してみてください。
まとめ：バックアップは「保険」ではなく「戦略」である
バックアップは、単なるデータのコピー作業ではありません。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との比較
実践へのステップ
このプロセスを確実に実行することで、あなたの組織は「想定外の事態」においても、冷静かつ迅速にビジネスを再生させることができるようになります。
情報処理安全確保支援士として、また実務担当者として、技術だけでなく「安心」を設計できるエンジニアを目指しましょう。バックアップ戦略は、災害や攻撃からビジネスを守る最後の砦です。その設計と運用に妥協は許されません。
今日から、自組織のバックアップ戦略を見直してみてください。RPOとRTOは明確に定義されていますか？リストアテストは実施していますか？3-2-1ルールは守られていますか？
これらの問いに自信を持って「Yes」と答えられる組織こそが、真に災害に強い、レジリエントな企業と言えるでしょう。
次回予告
次回は、BCP（事業継続計画）とDR（災害復旧）について、さらに組織論やガイドラインの観点から深掘りしていきます。データだけでなく、人やプロセスをどう守るか、という視点を学んでいきましょう。