世代管理不足で古いバックアップしか残っていない『バックアップ・DR（災害対策）の話④』
バックアップ自体は取れている。
でも 必要な日付のものが無い。
復旧しようにも、数週間前の状態しかない。
原因は 世代管理（保持ポリシー）を設計していないこと。
初学者が「とりあえず保存」で起こす、静かに致命的なミスだ。
冒頭の一言要約
バックアップは“新しさ”が命。
古い1世代だけでは、復旧の意味がない。
症状（あるある）
直近のバックアップが無い
週次1本だけ残っている
上書き保存で世代が消えている
世代数が不明で削除できない
どこまで戻れるか分からない
復旧後にデータ欠損が発覚
原因と仕組み（なぜ起きるか）
世代数・保持期間を決めていない
容量節約のために上書き保存
自動削除と自動作成の不整合
日次／週次／月次の区別がない
RPO を考えていない
バックアップ対象だけ見て“履歴”を見ていない
バックアップは
「いつに戻れるか」を決めて初めて機能する。
世代が足りないと、
復旧できても“業務的に使えない”状態になる。
図：世代不足の典型
[現在]
│
├─ 障害発生
│
[バックアップ]
└─ 1世代（2週間前）
↓
大量の差分が失われる
切り分け（最短コース）
保持されている世代の確認
何本、何日分あるか
直近成功分の日時確認
本当に毎日取れているか
自動削除ルール確認
いつ、何を消しているか
上書き保存の有無確認
業務的に許容できる復旧点確認
RPO の把握
今すぐ効く対処（テンプレ）
◆ 最低限の世代設計（例）
日次：7世代
週次：4世代
月次：3世代
→ 短期＋中期を必ず残す。
◆ 初学者向け現実解
まずは「直近7日」を確保
容量は後から調整
上書き保存は禁止
恒久対策／再発防止チェックリスト
世代数と保持期間を明文化
上書き保存を禁止
日次／週次／月次を分ける
自動作成と自動削除をセットで設計
RPO を関係者で合意
世代一覧を定期確認
復旧テストで日付指定を確認
容量監視を併用
落とし穴（やりがちミス）
バックアップが1本あれば安心
容量不足で勝手に削除
直近分が失敗しても気づかない
世代名が分からず触れない
復旧時に初めて世代不足を知る
まとめ（行動指針）
世代管理がないバックアップは、
「いつ戻れるか分からない保険」。
残す日数を決める → 世代を分ける → 定期確認する。
この3点を押さえるだけで、
“古すぎて使えない復旧”は確実に防げる。
