はじめに
事業継続に直結するデータバックアップは、もはやIT部門だけの課題ではありません。サイバー攻撃や誤操作、機器故障、自然災害は「いつか起きる」ではなく「いつでも起こり得る」と考えて設計することが前提です。単にコピーを作るだけでは不十分で、復旧可能な状態を継続的に維持するためのルール化と運用体制が欠かせません。
本稿では、世界標準とされる3-2-1ルールの正しい理解と実装手順、バックアップの世代管理（バージョン管理）の重要ポイント、クラウド利用時の注意点、ランサムウェア対策、導入ステップ、さらには3-2-1を拡張した最新モデルまでを、企業がすぐ実践できる形で整理します。RTO（復旧目標時間）とRPO（復旧目標時点）を軸に、実情に合った設計を進めましょう。
3-2-1ルールを正しく理解する
3-2-1ルールの意味と背景
3-2-1ルールは、バックアップ運用の基本を簡潔に示したガイドラインです。要点は次のとおりです。
- 3：データのコピーを合計3つ（元データ＋バックアップ2つ）
- 2：2種類以上の異なるメディアに保存
- 1：少なくとも1つはオフサイト（遠隔地）で保管
この考え方は単一障害点（SPOF）を排除し、物理的・論理的な障害両方に備えて復旧確率を高めます。現代の運用では、この原則をベースにクラウドやイミュータブル技術を組み合わせるのが一般的です。
企業のバックアップ戦略における位置づけ
バックアップはシステム復旧の一層であり、スナップショットやDR（災害対策）と組み合わせて全体のレジリエンスを作ります。下表は各レイヤーの目的とRTO/RPOの目安です。表の後に、それぞれのレイヤーがどのように相互補完するかを簡単に説明します。
| レイヤー | 目的 | 例 | RTO/RPOの目安 | 備考 |
|---|---|---|---|---|
| スナップショット | 短期的な巻き戻し | VM/DBの瞬時スナップショット | RTO:分〜時間/RPO:分 | 同一環境依存・破壊の連鎖リスク |
| バックアップ | 事業継続の主力 | 3-2-1準拠のフル/差分/増分 | RTO:時間/RPO:時間〜日 | 世代管理＋オフサイトが肝 |
| アーカイブ | 長期保存・証跡 | コンプライアンスデータ | RTO:日/RPO:日〜月 | 低頻度アクセス・低コスト |
| DR（災害対策） | 拠点障害に備える | 別リージョン待機系 | RTO:分〜時間/RPO:秒〜分 | コスト高も高可用性 |
実践することの主な利点
3-2-1ルールを実践すると、以下のような効果が期待できます。
- 体制の堅牢化と可用性の向上
単一障害点を避け、メディアや拠点ごとのリスクを分散できます。オンラインとオフラインを組み合わせることで、運用停止時間を短縮できます。
- 障害・事故時のデータ損失抑制
世代管理により、過去の任意時点への復元が可能となり、人的ミスやデータ破損に強くなります。
- 一部のバックアップが侵害されても復旧可能
ランサムウェアなどでオンラインコピーがやられても、オフサイトやオフラインのコピーから復旧できるため、RTOを安定させられます。
- コンプライアンス・経営面の貢献
業界規制や監査要件を満たすことで法令対応の安心感が増し、ダウンタイムを抑えることで顧客満足度やブランド維持にもつながります。
これらの利点は、ルールを実装して終わりではなく、定期的な検証と改善を重ねることで初めて実効性が高まります。
3-2-1ルールの内訳と実装ステップ
本章では、3-2-1ルールを技術的・構成的にどう実装するかを解説します。
“3”: 最低3つのバックアップコピーを保持する
3つのコピーは「選択肢の数」を意味します。典型的な配置は次のとおりです。
| 役割 | 位置づけ | 推奨保存先 | 主な用途 |
|---|---|---|---|
| プライマリ（運用） | 元データ | 本番システム | 日常業務 |
| セカンダリ（オンサイト） | 即時復旧用 | NAS/バックアップアプライアンス | 機器故障・誤消去に即応 |
| ターシャリ（オフサイト） | 重大障害・攻撃時 | クラウド/別拠点/テープ保管 | 災害・広域攻撃からの復旧 |
“2”: 異なる種類の保存媒体に分散する
メディアごとに故障モードやコスト、運用性が異なるため、複数種類の組み合わせが効果的です。下表は代表的なメディアと特徴です。
| メディア | 特長 | 長所 | 短所 | 向き/補足 |
|---|---|---|---|---|
| HDD/SSD（ローカル） | 高速・即時性 | 復元が速い | 同一拠点依存・攻撃に脆弱 | セカンダリに好適 |
| NAS/アプライアンス | 一元管理 | 重複排除・圧縮 | 製品依存・コスト | 中規模以上で有効 |
| テープ | 物理分離容易 | 低コスト長期保管 | 取り回し/人手 | 物理的エアギャップ（適切管理が前提） |
| クラウドオブジェクト | 可用性/耐久性 | 地理分散・スケール | 転送/運用コスト | オフサイトの第一候補 |
| WORM/イミュータブル | 改ざん不可 | ランサムに強い | 運用ルール要 | 重要データの盾 |
現場での組み合わせ例としては、内蔵HDD＋外付けHDD、NAS＋クラウドストレージ、外付けHDD＋テープなどが挙げられます。重要なのは、同じ故障パターンに同時に耐えられる構成にすることです。
“1”: 少なくとも1つは遠隔地へ退避する
オフサイトは自然災害や拠点全体の障害、広域攻撃に対する最後の防線です。実務上のポイントは次のとおりです。
- 退避先の選択肢（クラウド／別拠点／物理媒体）：
オフサイトはクラウド、別拠点、提携先の保管庫、テープ保管などが考えられます。
- オンサイトと分離したアカウント・権限設計：
オフサイトの管理は「同一アカウント／同一権限」に依存しないよう権限分離（別アカウントや別組織）を検討すること。
- 物理媒体利用時の暗号化と管理記録：
帯域や回線断に備え、定期的に物理搬送（テープ輸送）を併用するのは有効です。搬送時にはケース封印や媒体暗号化、チェーン・オブ・カストディの記録などで盗難・紛失対策を徹底してください。
- データ鮮度を前提としたスケジュール設計と整合性確認：
オフサイトはリアルタイム同期が難しく、オンサイトとのデータ鮮度差が生じる点を踏まえ、スケジュール設計や重複排除、整合性チェックを組み込みましょう。
実運用への落とし込み手順
実務で機能するバックアップ体制を作るには、設計→実装→検証という流れを厳格に回すことが重要です。
設計方針とバックアップポリシーの策定
まずは対象データの棚卸し（システム、ファイル、DB、メール、ログ、設定など）を行い、RTO・RPO・SLOや復旧優先順位を明確にします。保持期間（リテンション）や世代数（GFSなど）、復旧責任の範囲（社内／ベンダ／クラウド）も文書化してください。
媒体選定（オンプレミス/クラウド/テープ等）
媒体選定ではデータ特性（大容量の非構造化データか、DBか）、保持要件（法規制やイミュータブル要否）、コスト（CAPEX/OPEX）、運用性（自動化の度合い）を軸に判断します。下表を参考に要点を整理しましょう。
| 判断軸 | 例 | ポイント |
|---|---|---|
| データ特性 | 大容量非構造化/DB/VM | 書込み頻度・直近復旧の要否 |
| 保持要件 | 7年保管/改ざん防止 | WORM・Object Lock・法令 |
| コスト | CAPEX/OPEX | 容量成長率・転送料 |
| 運用 | 自動化/人手 | 無人運転・保守体制 |
スケジュール設計と自動化
運用ではフル／増分／差分の取得頻度、合成フルの有無、オフサイト複製のタイミング、整合性チェックの間隔を定めます。自動化によりヒューマンエラーを減らし、容量とウィンドウの最適化を図ります。
復元テストと監査手順の確立
定期的な復元テスト（四半期毎など）を実施し、0エラーでの復元、RTO/RPO達成、アプリ整合性の確認を必須にします。ジョブログやハッシュ、スクリーンショットなどの監査証跡を残し、想定外のインシデント訓練も運用に組み込みましょう。
クラウド活用時の注意事項
クラウドは耐久性やスケール性を提供しますが、「任せっぱなし」では危険です。主な設定と注意点は以下です。
| 機能/設定 | 目的 | 注意点 | 補足 |
|---|---|---|---|
| バージョニング | 誤削除対策 | コスト増加 | ライフサイクルで整理 |
| Object Lock/WORM | 改ざん防止 | 保持解除に厳格な制限（コンプライアンスモードでは不可） | 法的保持にも有効 |
| Cross-Region/アカウント複製 | リージョン障害/権限分離 | 転送料 | 断絶権限を意識 |
| 暗号化（KMS） | 機密性保護 | キーの分離管理 | キー削除権限を限定 |
| MFA Delete | 操作防御 | 対応範囲に差 | 重要バケットで必須 |
| ネットワーク制御 | 不正アクセス抑止 | 誤設定リスク | プライベート経路推奨 |
| 監査ログ/脅威検知 | 早期検知 | 保持/改ざん耐性 | ログも別保管 |
加えて、以下の点も必ず確認してください。
- 自動同期のリスク：
端末やサーバで感染したファイルが瞬時にクラウドへ同期されることがあるため、重要データは自動同期を無効にするか、スナップショットやバージョン履歴を必ず有効にする。
- 責任分界：
自社とクラウド事業者の責任範囲を文書化しておく。
- SLAの精査：
可用性やサポート範囲を契約前に確認。
- 転送時間・コストの評価：
RTO/RPOに照らして転送遅延やイグレス費用を見積もる。
クラウドは強力な選択肢ですが、設計と運用の注意点を押さえて使うことが重要です。
暗号化・アクセス制御などのセキュリティ対策
バックアップそのものを攻撃から守るための基本方針です。
- 暗号化：
保存時（at‑rest）と転送時（in‑transit）の暗号化を標準化し、キーはバックアップ環境外で分離管理する。
- アクセス制御：
最小権限（RBAC/IAM）とMFAを必須にし、緊急用アカウント（break‑glass）は封印運用と監査を行う。
- 管理面の分離：
本番とバックアップで管理者やアカウントを分け、横展開を防ぐ。
- 整合性検証：
ハッシュやデジタル署名で改ざんを検知できる仕組みを導入する。
- ランサム対策：
イミュータブル保管やスナップショット鎖の保護で攻撃耐性を高める。
これらは単独で有効な対策というより、重ねることで効果を発揮します。
バックアップの世代管理（バージョン管理）の要点
世代管理の基本概念
世代管理とは、一定期間にわたる複数のバックアップ時点を保持し、任意の時点へ復元できるようにする運用です。よく使われるパターンにGFS（Grandfather‑Father‑Son：日次/週次/月次）があり、例えば「日次14世代、週次4世代」を基準とする運用が一般的なベンチマークになります。
世代管理が不可欠な理由
世代管理を持つことで、次のようなリスクに備えられます。
- 時限式マルウェアへの備え
潜伏型のランサムウェアはバックアップにも侵入することがあります。長期世代を持つことで感染前の時点に戻せるため、少なくとも3世代以上の保存を下限に設計するのが安全です。
- 誤操作・論理障害からの巻き戻し
誤削除やデータのロジック障害に気づくのが数日〜数週間後でも、目的の時点へピンポイントで復元できます。
- コンプライアンスと監査対応
法的保持や証跡保存、改ざん防止（WORM）によって監査対応力が向上します。
世代管理を実現するバックアップ方式
方式ごとに特徴があり、復元手順やRTO/RPOの傾向も変わります。代表的な方式は次のとおりです。
| 方式 | 取得対象 | 容量/時間 | 復元手順 | RTO傾向 | RPO傾向 | 向き/注意 |
|---|---|---|---|---|---|---|
| フル | 全データ | 大 | シンプル | 速い | 取得頻度次第 | 基準点、頻度過多はコスト増 |
| 差分 | 前回フルからの差分 | 中（世代で増大） | フル＋差分 | 中 | 良 | 長期でサイズ肥大 |
| 増分 | 直前バックアップからの差分 | 小 | フル＋全増分 | 遅い（連鎖） | 最良 | どれか破損で復元不可リスク |
合成フル（増分から仮想的にフルを作る手法）や重複排除を活用すると、容量と復旧速度のバランスを改善できます。
リテンション設計と保管ポリシーの考え方
リテンションは直近は高頻度で短期保存、古い世代ほど間引いて長期化するのが基本です。代表的なパターンと用途の目安は次のとおりです。
| 代表パターン | 日次 | 週次 | 月次 | 年次 | 用途 |
|---|---|---|---|---|---|
| GFS（標準） | 30日 | 8週 | 12カ月 | 7年 | ほとんどの業務 |
| 開発/高速変更 | 14日（1日2回） | 4週 | 6カ月 | – | 頻繁な変更と速復旧 |
| 高規制対応 | 60日 | 12週 | 84カ月 | 10年 | 金融/医療など |
設計のコツとしては、重要データはイミュータブルやWORMで一定期間ロックし、ストレージ見積もりは「基準フルサイズ＋平均変更率×世代数」でざっくり試算しておくとよいでしょう。
企業導入の進め方と運用体制づくり
自社データ特性と要件の棚卸し
導入の第一歩は、データごとのクリティカル度、データ量と増分率、法規要件、保管場所の制約などを整理することです。これによりRTO/RPOや保持期間の優先順位が見えてきます。
運用時に注意すべきリスクと対策
3-2-1ルールの導入は復旧力を高める一方で、コスト増や運用の複雑化、攻撃対象の拡大といった新たな課題も生じます。企業導入にあたっては、これらのトレードオフを前提に体制を設計することが重要です。
具体的には、複数メディア・拠点の運用によるコスト増に対しては、重複排除や圧縮、自動化によって運用負荷を抑えます。また、バックアップコピーが増えるほど攻撃対象も広がるため、オンサイトとオフサイトでの権限分離や別アカウント運用を徹底する必要があります。
さらに、増分バックアップの連鎖が長くなると復旧手順が複雑化するため、合成フルの活用や手順書の標準化、定期的な復旧訓練が不可欠です。クラウドを利用する場合は、設定不備や鍵管理の不整合が大きなリスクとなるため、セキュアデフォルトやMFA、KMSの分離といった基本対策を前提としてください。
3-2-1ルールに基づく社内バックアップ体制の構築
最低ラインと望ましい状態の目安は次の通りです。まずは最低ラインから着手し、運用成熟度に応じて望ましい状態へと引き上げるのが現実的です。
| 項目 | 最低ライン | 望ましい状態 |
|---|---|---|
| コピー数/媒体 | 3コピー/2媒体/1オフサイト | ＋イミュータブル/別アカウント |
| 自動化 | 取得/複製の自動化 | 異常時通知/自己修復 |
| モニタリング | 成功/失敗の可視化 | 成功率SLO/容量予兆 |
権限設計と運用プロセスの標準化
バックアップ作業は申請→承認→実行→レビューのワークフローに落とし込み、職務分掌を明確にしてください。監査ログは改ざん耐性を持たせることが重要です。
従業員教育とバックアップ意識の向上
誤操作やフィッシングが脅威の入口となるため、定期的な教育や訓練が必要です。バックアップ手順書やベストプラクティスを共有し、社内ポスターやリマインダーで継続的に意識付けを行いましょう。現場からのフィードバックを受けて改善する仕組みも組み込みます。
ルール順守による事業継続（BCP）の確保
復旧優先順位や代替手段（手作業・縮退運転）を明文化し、年1回の全社DR訓練を推奨します。期待される効果はダウンタイムの短縮、顧客満足度の維持、ブランド保護、法令順守などです。
定期的な見直しと継続的改善（PDCA）
- P（Plan）：要件・RTO/RPOの再評価
- D（Do）：自動化ジョブの更新や環境変更の反映
- C（Check）：検証復元のKPI（成功率・所要時間）を監視
- A（Act）：リテンションや媒体構成の調整
このサイクルを回すことで、技術や業務変化に追随できる体制になります。
3-2-1を補完・拡張する近年のアプローチ
3-2-2モデル
オフサイトを2系統用意（例：別リージョン＋別クラウド事業者）することで、単一リージョン障害やクラウド事業者側の広域障害といった想定外の事象にも耐性を高められます。特にリージョン冗長と事業者分散を組み合わせることで、自然災害や大規模障害、サービス停止リスクを同時に回避でき、バックアップの可用性と信頼性をより高い水準で確保できます。
4-3-2モデル
コピーを4系統、異なる媒体を3種類、オフサイトを2か所に分散する4-3-2モデルは、停止やデータ損失が許容されないミッションクリティカルなシステムや、高い規制要件を持つ業界に適した構成です。運用コストや設計難易度は上がるものの、単一障害点を極力排除でき、広域災害や複合障害に対しても非常に高い可用性と復旧力を確保できます。
3-2-1-1-0モデル
3-2-1ルールに「＋1（オフラインまたはイミュータブル）」と「0（検証エラーゼロ）」を加えた考え方です。追加の“1”は、物理的または論理的に改ざんできないコピーを保持することを指し、ランサムウェアや内部不正への耐性を高めます。
“0”は、定期的なリストア検証を通じてエラーのない世代のみを復旧対象とする運用を意味し、「バックアップはあるが復元できない」状態を排除することを目的とします。高い安全性が求められる環境では、実効性を重視した現実的な進化形モデルといえます。
追加の“1”で強化するオフライン/オフサイト冗長化
攻撃の到達可能性を物理的に断つ「触れないコピー」を最低1つ確保することで、ランサムウェアや内通者のリスクを大幅に低減できます。
“0”が求める検証エラーゼロの考え方
単なるバックアップの存在ではなく、定期的な復元検証と整合性チェックを通過した世代だけを「復旧可能」として扱う運用にすることで、実際に使えるバックアップだけを信頼できるようにします。
おわりに
バックアップルールは導入して終わりではなく、日々の検証と改善で強くなります。3-2-1を土台に世代管理で任意時点復旧を担保し、イミュータブルやエアギャップで攻撃耐性を高める。RTO/RPOに合った媒体・頻度・保持を継続的に最適化することが、最短の復旧と損失最小化につながります。
まずは現状の棚卸しと3-2-1準拠のギャップ把握から始めましょう。オフサイト確保、権限分離、復旧テストの定例化といった“効く打ち手”を優先的に実装し、事業継続に直結するバックアップ体制を作り上げてください。
