1 概要
1.1 定義
バックアップ世代管理とは、バックアップデータを単一の保存点に限定せず、複数の世代として時系列に分けて保管し、必要に応じて過去の時点に復元できるようにする運用方法である。ここでいう「世代」は、作成時刻や世代番号により整理されたバックアップの集合を指し、直近のみを残すのではなく、一定期間または一定回数の更新分を保持する点が特徴である。
1.2 目的
主目的は、復旧可能性の向上である。具体的には、誤って削除した、データが破損した、マルウェアの影響が判明した、システム更新に失敗したといった事象に対して、最新のバックアップでは復旧できない場合でも、より前の世代へ切り戻すことで被害を限定できるようにする。
1.3 基本的な考え方
世代管理は、保持する「期間」と「世代数」、さらに「更新頻度」と「保存先」を組み合わせて設計される。復元時に参照する候補を増やせば復旧の選択肢は増えるが、その分だけ保管容量や管理作業の負担が増える。したがって、業務の重要度、許容停止時間（RTO）、許容データ損失量（RPO）、保管コスト、復元手順の実装容易性などを同時に考慮し、最適点を見つけることが基本となる。
2 世代管理の方式
2.1 差分保存方式
差分保存方式では、基準となる完全保存（フルバックアップ）以降に発生した変更分を、毎回の差分バックアップとして保存する。復元する際は、基準の完全保存に加えて、必要な時点までの差分を適用することで当該時点の状態を再構成する。変更量が比較的安定している領域では、単純化された計算で運用しやすい。
2.2 増分保存方式
増分保存方式では、前回のバックアップ以降の変更分だけを保存する。復元には、最初の完全保存から始まり、対象時点に到達するまでの増分を順番に適用する必要がある。復元手順は複数段の適用となりやすい一方、差分方式に比べて必要な保存容量を抑えられる場合がある。
2.3 完全保存方式
完全保存方式は、各バックアップの実行時に対象全体のデータをそのまま保存する。復元は該当する時点の完全保存を選ぶだけで済みやすく、手順の複雑さが低い。反面、毎回の保存容量や実行時間が増えやすく、大規模環境ではコスト面が制約になりやすい。
2.4 組み合わせ方式
組み合わせ方式は、上記の要素を組み合わせて運用負荷と復元性を調整する考え方である。典型例として、定期的に完全保存を実施し、日次は増分、あるいは日次は差分といった運用が挙げられる。世代の設計と合わせて、復元時に必要な適用回数が現実的な範囲に収まるよう調整する。
3 世代数と保持期間の設計
3.1 保存世代数の決め方
保存世代数は、「どの程度の過去の時点へ戻す必要があるか」と「復旧で重視するイベントの頻度」によって決める。例えば、誤削除が起きた場合に備えて直近数回を厚くする、あるいは更新失敗の発生パターンに合わせて直近の数週間を確実に復元可能にする、などの要件整理が出発点となる。世代数を増やすほど選択肢は増えるが、ローテーション設計と整合した管理が必要になる。
3.2 保持期間の決め方
保持期間は、時系列に沿って必要な復元点の「到達可能性」を保証するための時間幅として扱われる。業務上の記録要件、監査や事後調査の可能性、保存コスト、バックアップの取得頻度を踏まえて決める。運用面では、保持期間の長さだけでなく、復元時に参照できる具体的な世代（いつ作られたバックアップか）を明確化することが重要となる。
3.3 容量と復元性のバランス
保持の設計は、容量制約と復元のしやすさ（手順の短さ、失敗しにくさ、対象時点の粒度）を同時に満たすことが目標となる。バックアップ方式（完全・増分・差分）と世代数、保持期間、保存先の違いが複合的に影響するため、机上計算と実測の両面から見直しを行うのが実務的である。
3.3.1 保存容量の見積もり
保存容量の見積もりでは、対象データの総量、変更率、バックアップ方式ごとの増分／差分の想定量、世代ごとの上限を算定する。さらに、メタデータや重複排除の有無、圧縮の効果、ファイルシステムの扱いなども考慮対象になる。見積もりは精緻であるほど良いが、運用を回しながら更新する前提で「現実的な幅」を設けると計画が破綻しにくい。
3.3.2 復元時点の選択性
復元時点の選択性は、ユーザーが希望する時刻に近いバックアップが存在するか、またその復元が現実的な手順で完了するかで評価される。例えば、日次でしか作らない場合は数時間単位での復元精度が上がらない。一方で世代を細かく増やすと保管量が増えやすい。復元時点の粒度と、復元手順に含まれる適用回数（増分方式など）を合わせて設計する。
4 運用と管理
4.1 バックアップの実行計画
実行計画は、いつ、何を、どの手順で取得するかを定める工程である。取得時間は業務負荷を考慮し、同時実行の有無やネットワーク帯域の利用を勘案する。加えて、失敗時の扱い（再実行、通知、保留、切り替え）をあらかじめ定義し、運用者の判断に依存しない形にすることで事故率を下げられる。
4.2 世代のローテーション
世代ローテーションは、保持ポリシーに基づき、古い世代を削除またはアーカイブへ移す仕組みである。削除基準は単純な「上限数」だけでなく、保持期間と世代の対応づけ（例えば日次は一定日数、週次は一定週数など）によって段階的に構成することが多い。重要なのは、削除対象が復元要件から外れていることを一貫して検証する点である。
4.3 保存先の管理
保存先は、媒体や場所の違いにより耐障害性と復旧性が変わる。世代管理の効果を引き出すには、保存先の多様性を設計し、単一の障害や事故で全世代が失われない状態を目指す。
4.3.1 同一媒体での保管
同一媒体での保管は運用が簡便な一方、媒体障害や誤消去の影響が広がりやすい。差分・増分の整合性や世代の連鎖がある場合、ある世代の破損が後続復元に波及する可能性もある。小規模環境や補助的用途では成立する場合があるが、重要データではリスク評価を行う必要がある。
4.3.2 異なる媒体での保管
異なる媒体へ分散することで、物理的な故障や媒体固有の不具合の影響を抑える。例えば、ローカルのストレージとリムーバブル媒体、別のストレージクラスなどを組み合わせると、復元の選択肢が広がる。媒体ごとの取り扱い手順（取り外し、暗号化、ラベル管理）も含めて運用標準化が求められる。
4.3.3 別拠点での保管
別拠点での保管は、局所的な災害や環境トラブルに対する保険になる。距離や回線品質、移送時間の制約があるため、全量を常時転送するのか、段階的に複製するのかを決める必要がある。世代管理の観点では、復元に必要な時点のバックアップが実際に到達しているか（転送失敗や遅延の有無）を定期的に点検する。
4.4 復元テスト
復元テストは、バックアップが存在するだけでは不十分であることを前提に、実際に復元できるかを確認する活動である。対象ファイルの読み出し、整合性チェック、復元後の起動・アプリケーション稼働までの確認など、段階的な検証が用いられる。テスト頻度は保持期間や重要度に応じて決め、結果は運用改善に反映する。
5 代表的な設定例
5.1 日次バックアップ
日次バックアップは、通常の運用で毎日取得し、直近の更新に対する復旧点を確保する方式である。世代管理では、日次分を一定日数保持し、週次や月次といった長期保存の枠へローテーションで移行させる設計が一般的である。増分または差分を用いることで保存容量を抑え、復元テストで粒度の妥当性を確認する。
5.2 週次バックアップ
週次バックアップは、日次でカバーできない期間の復元点を補完する役割を担う。多くの場合、週のどこかで完全保存、またはより厚い差分／増分の取得を行い、復元手順の段数を抑える工夫が入る。保持期間を延ばす際は、保管容量と復元の現実性を見直しながら調整する。
5.3 月次バックアップ
月次バックアップは、長期の保全と監査対応、事後調査のための復元を意識して作られる。日次・週次の累積では運用負荷が増えるため、月次ではより作成間隔を広げ、必要な時点へ戻せる最小限の世代を維持する構成が取りやすい。アーカイブ要素を併用し、読み出し手順や暗号化鍵の管理も合わせて整備する。
5.4 複数世代の組み合わせ例
複数世代の組み合わせ例として、日次は増分で数日〜数週間、週次は差分や完全保存で数週間〜数か月、月次は完全保存で数か月〜年単位といった階層設計が挙げられる。ここでは、復元時に必要な適用回数が上限を超えないこと、主要な復元パターン（誤削除、破損、更新失敗）がカバーされること、ローテーションが要件と矛盾しないことを確認する。
6 利点と課題
6.1 利点
6.1.1 誤操作への対応
誤って削除や上書きを行った場合、最新のバックアップが同じ誤状態を含む可能性がある。世代を複数保持していれば、誤操作が起きる前の状態へ戻せるため、復旧の成功率が高まる。特に作業手順の複雑な環境では、時間的余裕を提供する点が実用上の価値になる。
6.1.2 障害時の復旧性向上
媒体障害、破損、更新失敗などで復元候補が失われるケースにおいて、世代の選択肢があることで代替ルートを確保できる。復元テストによって「復元可能な世代」を把握できれば、実事故時の判断が速くなり、停止時間の短縮につながる。
6.2 課題
6.2.1 保存容量の増加
保持期間や世代数を増やすと、必要な容量は概ね増加する。増分や差分を使う場合も、差分が肥大化する時期や、復元に必要な参照世代が増える状況では負担が上がる。容量計画を定期的に見直さないと、ローテーションが機能不全に陥りやすい。
6.2.2 管理の複雑化
世代管理は、作成方式、保持ポリシー、削除基準、保存先の状態監視など、管理項目が増える。世代の対応関係が曖昧だと復元時に迷いやすく、運用ミスの温床になる。手順書の整備、命名規則、ログの監査可能性の確保が重要になる。
6.2.3 古い世代の安全性
古い世代は、保存媒体の劣化や鍵管理の変更、環境移行による読み出し手段の陳腐化などの影響を受けうる。復元テストを継続しないと、後になって「存在するが復元できない」状態が見つかるリスクが高まる。安全性の担保には、保存だけでなく長期運用の見通しが必要である。
7 関連技術
7.1 バックアップソフトウェア
バックアップソフトウェアは、取得、世代管理、暗号化、圧縮、整合性検証、世代削除などの機能を提供する。運用では、バックアップ方式の選択、スケジューリング、失敗時の扱い、ログの出力形式、復元の手順と権限管理の容易さが評価対象になる。ツール選定は機能だけでなく、運用者が再現可能な手順で扱えるかも含めて行う。
7.2 スナップショット
スナップショットは、ある時点の状態を論理的またはメタデータベースで記録し、参照や復元を行う技術である。世代管理との関係では、短い間隔での復元点を作りやすく、復旧手順の迅速化に寄与する場合がある。もっとも、スナップショットが保持する前提（基盤ストレージの挙動、保持期間、削除ポリシー）を理解して運用設計に組み込む必要がある。
7.3 アーカイブ
アーカイブは、長期保存を目的としてデータを別の保存区画へ移す考え方である。世代管理では、運用上不要になった世代でも、監査や後日の参照に必要なものを残す役割を担う。読み出しコストや復元速度の制約があるため、復元テストや手順確認の対象に含めると不確実性を減らせる。
7.4 災害対策と復旧計画
災害対策と復旧計画は、バックアップを「保持する」だけではなく、「いつ、どの順序で復旧し、誰が判断するか」を含めて定める枠組みである。世代管理は復旧計画の復元点（いつの状態へ戻すか）を具体化する要素として位置づく。回線断絶や権限喪失などの想定も含め、復旧手順と世代の参照方法が整合していることが求められる。