バックアップを「復旧できる形」にする方法（3-2-1と世代管理）

なぜ「バックアップがあるのに復旧できない」が起きるのか

ランサムウェア被害やクラウド障害のニュースを見るたびに「うちはバックアップしているから大丈夫」と思いがちです。しかし現場では、バックアップが存在しても“復旧できる状態”になっていないケースが少なくありません。とくに情シスが少人数、あるいは専任不在の中小企業では「取れている＝守れている」と誤解しやすいポイントです。

典型的な失敗は次の通りです。①バックアップ先が同じネットワーク上にあり、攻撃者に暗号化・削除される（バックアップも巻き添え）。②世代が少なく、気づいた時には壊れたデータで上書きされている。③復元手順や権限が整っておらず、いざという時に戻せない。④復元テストをしておらず、実は必要なファイルが取れていない。⑤SaaSの「同期」をバックアップと勘違いしている（削除・改ざんがそのまま同期される）。

さらにセキュリティの観点では、バックアップは「最後の砦」である一方、「攻撃者が狙う高価値資産」にもなります。バックアップがある会社は復旧できるため身代金を払わない可能性が上がります。だからこそ攻撃者は、最初にバックアップを探して消しに来ます。つまり、バックアップ設計は“保存”だけでなく“破壊されにくさ”まで含めて考える必要があります。

本記事では、非エンジニアでも意思決定できるように、復旧に直結する考え方として「3-2-1」と「世代管理（世代保持）」を軸に、導入・運用・点検までを実務目線で解説します。

復旧できるバックアップの合格ライン（RTO/RPOを決める）

「復旧できる形」を定義するために、まずは復旧の目標を決めます。難しい用語に見えますが、要点はシンプルです。どれくらい早く（時間）・どれくらい前の状態に（データ）戻せれば事業が止まらないかを決めるだけです。

• RTO（復旧時間目標）：止まってから復旧まで許容できる時間（例：8時間以内、翌営業日まで）
• RPO（復旧時点目標）：どこまでのデータ損失が許容できるか（例：1時間前、前日夜、週次）

例を挙げます。受発注が止まると売上に直結する会社は「RTO：数時間」「RPO：1時間〜当日中」を求めることが多いです。一方、月次の集計が中心なら「RTO：翌日」「RPO：前日夜」でよい場合もあります。ここを曖昧にすると、バックアップの頻度・保管先・コストの最適化ができません。

次に、対象範囲を棚卸しします。「PCのデータだけ」「ファイルサーバだけ」では足りないことがよくあります。たとえば、業務は動いているのにログインできない、という事態は、ID管理（Active Directory等）やクラウドの設定情報が戻らないことが原因になりがちです。最低でも次を区分して考えると抜け漏れが減ります。

• 業務データ：ファイルサーバ、NAS、DB、共有フォルダ
• 基幹・業務システム：オンプレ、IaaS上の仮想マシン、コンテナ
• SaaS：Microsoft 365、Google Workspace、Salesforce等（メール・ファイル・設定）
• 認証・権限：ID管理、管理者アカウント、APIキー、証明書
• 構成情報：ネットワーク機器設定、クラウド設定、IaC（あるなら）

この棚卸しはセキュリティ対策そのものでもあります。重要データの所在が曖昧だと、バックアップも暗号化も権限管理も中途半端になります。まず「何を守るか」を言語化し、RTO/RPOとセットで合意しておくことが、復旧に強いバックアップの土台です。

3-2-1ルール：攻撃・故障・ミスに強い“置き方”の基本

3-2-1ルールは、バックアップの定番原則です。難しく捉える必要はなく、データのコピーを複数つくり、媒体と場所を分けるという考え方です。

• 3：データを合計3つ持つ（本番1＋バックアップ2）
• 2：2種類の異なる媒体に保存（例：NAS＋クラウド、ディスク＋テープ）
• 1：1つはオフサイト（拠点外・クラウドなど）に置く

これが効く理由は、事故のタイプが違うからです。HDD故障には同一拠点の別ディスクが効きますが、火災・水害・盗難にはオフサイトが効きます。操作ミスや内部不正には世代管理が効きます。ランサムウェアには「ネットワーク的に隔離されたバックアップ」や「削除できない仕組み」が効きます。3-2-1はそれらをバランスよく満たしやすい最小構成です。

中小企業・情シス少人数でも現実的な例を挙げます。

• 例A（ファイル中心）：本番（ファイルサーバ）＋同拠点NASへの定期バックアップ＋クラウドストレージ（オブジェクトストレージ等）へ世代付きで複製
• 例B（仮想基盤あり）：本番VMスナップショット（短期）＋バックアップサーバ（別筐体）＋クラウド保管（長期・改ざん不可）
• 例C（SaaS中心）：SaaSの標準機能＋サードパーティのSaaSバックアップ＋重要データの定期エクスポートを別保管

ポイントは、オフサイトが「同じアカウント・同じ権限」で管理されていると、攻撃時にまとめて消される可能性があることです。セキュリティの実務では「分けたつもりが、権限が一緒で結局一緒に消える」がよく起きます。3-2-1は“場所”だけでなく“管理権限の分離”まで意識して初めて強くなります。

世代管理（バージョン管理）の設計：いつの状態に戻せるかが命

バックアップの価値は「何日前に戻せるか」で決まります。世代管理（世代保持、バージョニング）とは、過去の複数時点のバックアップを残すことです。最新だけを持つバックアップは、事故が“気づいた時点”より前に起きていると役に立ちません。

例えば次のような事故は、発生から発覚までタイムラグがあります。

• ランサムウェアが段階的に暗号化し、数日後に影響が顕在化
• 誤操作でフォルダ削除したが、気づいたのが翌週
• 会計データが静かに改ざんされ、月次締めで発覚

世代設計の考え方は「短期は細かく、長期は粗く」です。業務上の戻しニーズは直近に集中し、古いほど参照頻度が落ちるためです。以下はあくまでたたき台ですが、多くの企業で説明が通りやすい形です。

• 日次：直近14〜30日分（毎日）
• 週次：直近8〜12週分（毎週）
• 月次：直近12〜36か月分（毎月）

重要なのは、世代を増やすほどストレージコストが上がる点です。ここは技術ではなく設計の工夫で最適化できます。具体的には、差分バックアップや重複排除、圧縮が効く方式を選ぶ、あるいは「重要フォルダは長期保持、その他は短期保持」のようにデータの重要度で分けます。

また、世代管理は「保存しているつもり」になりやすいので、定義を明文化します。たとえば「月次は月末時点のスナップショットを3年」など、いつの時点のデータが残るのかを決めます。曖昧だと復旧時に「欲しい日がない」問題が起きます。

セキュリティ上の注意として、世代管理があっても、攻撃者がバックアップ自体を削除できる権限を持っていれば意味がありません。次章の「改ざん・削除されにくい仕組み」とセットで考えてください。

ランサムウェア時代の必須条件：改ざん・削除されにくいバックアップ

ランサムウェア対策としてのバックアップは、単にオフサイトに置くだけでは不十分です。攻撃者は管理者権限を奪い、バックアップを削除してから暗号化することがあります。そこで重要になるのが、バックアップを“消せない・書き換えられない”状態で保持するという考え方です。

代表的なアプローチは次の通りです（製品名ではなく考え方で理解できます）。

• イミュータブル（変更不可）保管：一定期間、削除・上書きをできなくする（WORM相当）
• オフライン／エアギャップ：普段はネットワークから切り離す（定期接続の外付け媒体・テープ等）
• 権限分離：本番の管理者とバックアップ保管の管理者を分ける（別アカウント、別MFA、別責任者）
• バックアップ環境の監視：大量削除・失敗率上昇・暗号化兆候をアラート

特に権限分離は、費用をあまりかけずに効果を出せることがあります。例として、バックアップ保管先のクラウドアカウントを本番と分ける、保管先は「書き込み専用」にして削除権限を持つアカウントを限定する、管理者操作はMFA必須にし、緊急時のみ使うブレークグラス（緊急用）アカウントを厳格に管理する、といった運用です。

さらにセキュリティの盲点として「バックアップデータ自体の情報漏えい」があります。オフサイトやクラウドに置くほど、持ち出し・共有のリスクが増えます。対策としては、保管データの暗号化、アクセスログの保存、最小権限、委託先の取り扱いルール（契約・運用）が重要です。バックアップは守りの施策ですが、同時に“機密情報の塊”を別場所に作る行為でもあるため、漏えい対策まで含めて設計しましょう。

復旧できる運用の手順：バックアップ計画・テスト・手順書

設計が良くても、運用で崩れます。復旧を成功させるために、最低限押さえるべき運用は「計画」「テスト」「手順書」の3点です。復元テストをしていないバックアップは、保険証券の中身を読まずに契約しているのと同じです。

バックアップ計画（頻度・対象・責任者）

RTO/RPOに沿って、何をどの頻度で取るかを決め、責任者を明確にします。例：

• ファイル：日次（夜間）＋重要フォルダは1時間ごと差分
• DB：トランザクションログを短間隔＋日次フル
• 仮想マシン：日次イメージ＋短期スナップショット
• SaaS：日次バックアップ＋月次エクスポート

「全部毎時」はコストも運用負荷も跳ねるため、重要度別に分けるのが現実的です。

復元テスト（年1では足りないことも）

テストには段階があります。最初から大規模なDR訓練をやる必要はありません。

1. ファイル単体復元：誤削除を想定し、特定ファイルを復元できるか
2. システム復元：サーバ1台（またはVM）を別環境へ復元し起動確認
3. 業務復旧：担当部門がログインし、主要業務が回るか（帳票出力など）

頻度の目安は四半期に1回の小テスト＋年1回の大テストです。少なくとも、環境変更（サーバ更改、SaaS移行、権限変更）の後は必ず実施します。ここを怠ると「復元先の容量不足」「復元できてもアプリが動かない」「権限が戻らない」などが本番で露呈します。

手順書（誰が・何を・どの順で）

障害時は判断が遅れます。だから手順書は、技術者向けの詳細だけでなく、非専門家でも動けるように「連絡先」「意思決定ポイント」「優先順位」を含めます。

• インシデント判定：ランサムウェア疑い時はネットワーク遮断を優先、電源断の可否など
• 復旧の優先順位：認証基盤→ファイル→基幹→周辺、など業務順
• 復元の要件：いつの世代を戻すか（RPO）、どの環境に戻すか
• 社内外連絡：経営、法務、顧客、委託先、保険会社、監督官庁等

セキュリティ対応としては、ログ保全や証拠保全も重要です。復旧を急ぐあまり証拠が消えると、原因究明や再発防止、対外説明が難しくなります。可能であれば、復旧と並行して専門家に調査を依頼できる体制も準備しておくと安心です。

よくある質問（非エンジニア向け）：判断に迷うポイントを整理

最後に、予算はあるが詳しくない担当者が迷いやすいポイントをQ&Aで整理します。

同期（クラウドドライブ）とバックアップは何が違う？

同期は「同じ状態を複製する」仕組みなので、誤削除・改ざん・暗号化もそのまま広がります。バックアップは「過去の状態を残す」仕組みで、世代管理が前提です。同期は便利ですが、バックアップの代わりにはなりません。

スナップショットがあれば十分？

スナップショットは高速復元に有効ですが、同じストレージ・同じ権限の中にあることが多く、災害・機器故障・権限侵害に弱い場合があります。3-2-1の「オフサイト」「媒体分離」と組み合わせると強くなります。

クラウドに置けば安全？

クラウドは堅牢ですが「設定と権限」は利用者側の責任です。誤設定で公開される、管理アカウントを奪われる、削除権限が広すぎる、といった事故は起きます。セキュリティは場所ではなく運用で決まる面が大きいです。

何にお金をかけると効果が高い？

優先順位は一般に、①世代管理（戻せる期間）②改ざん・削除耐性（イミュータブル／権限分離）③復元テストと手順書、です。バックアップ容量を増やすだけより、復旧成功率に直結します。

まとめ

バックアップを「復旧できる形」にするには、保存先を用意するだけでは足りません。3-2-1で“壊れ方の違い”に備え、世代管理で“気づくまでの遅れ”に備えることが要点です。さらにランサムウェア時代は、バックアップが真っ先に狙われるため、改ざん・削除されにくい設計（イミュータブル、権限分離、監視）と、復元テスト・手順書まで含めた運用が不可欠です。

まずは、RTO/RPOの合意、対象データの棚卸し、現状バックアップの「置き方（3-2-1）」「戻し方（世代）」「消されにくさ（権限・変更不可）」を点検してみてください。小さな復元テストを一度回すだけでも、弱点が具体的に見えるようになります。セキュリティ対策は“やっている感”ではなく、復旧という結果で評価されます。