アプリケーション整合性のないバックアップ『バックアップ・DR（災害対策）の話⑦』
バックアップは成功している。
サイズも正常。
なのに、いざ 復元すると壊れている。
原因は アプリケーション整合性を取らずに取得したバックアップ。
初学者が「コピーできればOK」で起こす、復旧不能に直結する事故だ。
冒頭の一言要約
バックアップは“止めずに取る”だけでは足りない。
“止めた状態と同じ”で取らないと使えない。
症状（あるある）
DB が起動しない
起動してもテーブル破損
ロールフォワードが失敗
ファイルはあるが読めない
リストア後にアプリエラー多発
復旧したのに再構築になる
原因と仕組み（なぜ起きるか）
稼働中のファイルをそのままコピー
メモリ上データが未書込みのまま
トランザクション途中状態を保存
DB/アプリのスナップショット手順未実施
fsync / flush を理解していない
静止点（quiesce）を取っていない
アプリやDBは
複数ファイルで一つの状態を構成する。
途中状態を保存すると、
論理的に壊れたデータが完成する。
図：不整合バックアップのイメージ
[書込み中]
A更新完了
B未書込み
│
▼
[バックアップ取得]
↓
A新 / B旧 → 不整合データ
切り分け（最短コース）
取得方法確認
ファイルコピーのみか
アプリ停止有無確認
停止／スナップショット手順
DBログ状態確認
redo / journal
リストアエラー確認
整合性チェック結果
再現テスト
同条件で取得→復元
今すぐ効く対処（テンプレ）
◆ 正しい取得方法の原則
DB：ダンプ／専用バックアップコマンド
VM：スナップショット（整合性モード）
FS：freeze / flush 実施
※ “アプリが理解できる方法”で取る。
◆ 簡易対策
短時間停止して取得
書込みを止めてから保存
恒久対策／再発防止チェックリスト
アプリ整合性対応の手段を確認
バックアップ方式を明文化
静止点取得手順を用意
DB専用ツールを使用
リストア検証を必ず実施
VMスナップショット設定確認
運用手順を自動化
「コピー＝バックアップ」を禁止
落とし穴（やりがちミス）
ファイルコピーで十分と思う
スナップショットを万能視
DBログを理解していない
無停止にこだわる
成功ログだけ確認
まとめ（行動指針）
バックアップの本質は、
“同じ状態を再現できるか”。
止める → 揃える → 取る。
この順番を守るだけで、
復元不能なバックアップはなくなる。
