バックアップ整合性とポイントインタイムリカバリ

なぜ「コピーが取れている」だけでは復元できないのか

バックアップの本質は「コピーを作ること」ではなく「任意の障害時点から、整合した状態へ戻せること」です。ここを取り違えると、毎晩バックアップが成功しているのに、いざ復元すると壊れたデータベースが立ち上がる——という典型的な事故が起きます。原因のほとんどは、コピーを取った瞬間のデータが 整合していなかった ことにあります。

稼働中のシステムは、メモリ上のバッファ、書き込み途中のページ、まだディスクへ落ちていないトランザクションを常に抱えています。その最中にディスクをまるごとコピーすれば、得られるのは「ある瞬間のディスクの断面」であって、「アプリケーションとして筋の通った状態」ではありません。本記事では、整合性の段階（クラッシュ整合／アプリ整合）、quiesceとログ適用による任意時点復元（PITR）、そして「復元できないバックアップは無価値」という最終原則を、内部動作から解きほぐします。

整合性の二段階：クラッシュ整合とアプリ整合

スナップショットが持つ整合性には段階があります。混同しやすいですが、復元の成否を分ける決定的な区別です。

最も危険なのが3行目の 不整合 です。ファイルを順に読みながらコピーする間にも書き込みが進めば、先頭付近は古く末尾付近は新しい、時刻のねじれた断面ができます。インデックスは新しいのに本体は古い、といった構造的破綻が起き、復元しても使い物になりません。だからスナップショットは「ある一瞬で原子的に」撮る必要があります。LVMやストレージ層のスナップショット、コピーオンライト（CoW）ファイルシステムは、この「一瞬の断面を凍結する」ための仕組みです。

quiesce／フリーズ：静止点を作る

アプリ整合スナップショットを撮る要は quiesce（静止化） です。手順は概ね次の三段です。

1. アプリへ「今からスナップショットを撮る」と通知し、
   進行中のトランザクションを区切り、メモリ上のダーティバッファを
   ディスクへフラッシュさせる（必要なら一時的に書き込みを止める＝フリーズ）
2. その静止した一瞬で、ストレージ層が原子的にスナップショットを撮る
3. 直ちにアプリの書き込みを再開（thaw）。フリーズ時間は最小化する

肝は、書き込みを止める時間（フリーズ窓）を限りなく短く保つ ことです。スナップショット自体はCoWにより「その瞬間のブロックを以後の上書きから守る」だけなので、撮影は瞬時に終わり、データの物理コピーは裏でゆっくり進められます。OS側にも、ファイルシステムをフラッシュして書き込みを一時凍結するフリーズ／解凍の仕組みがあり、整合した断面を撮るための窓を提供します。DB側のフック（バックアップモードへの切り替えやフラッシュ＋ロック）と、ストレージ側のスナップショットを協調させるのが定石です。

WALとログ適用：そもそも復旧はどう成り立つか

PITRを理解する前提として、データベースの 先行書き込みログ（WAL: Write-Ahead Log） の役割を押さえます。原則は単純です——データ本体（ページ）を書き換える前に、その変更を必ずログへ先に書く。ログが永続化された時点でトランザクションはコミット成立とみなせ、本体への反映は遅延してよい。

書き込みの順序（先行書き込みプロトコル）:
  変更をWALへ追記 → fsyncでログを永続化 → コミット応答
  （データページ本体への反映は後で非同期にまとめて行う）

クラッシュ後のリカバリ:
  REDO  : コミット済みだが本体未反映の変更を、ログから再適用して進める
  UNDO  : 未コミットのまま本体に漏れた変更を、ログを使って巻き戻す

この仕組みのおかげで、クラッシュ整合な断面（電源断相当）からでも、起動時にWALを読んでREDO/UNDOを行えば、コミット境界で筋の通った状態へ戻せます。WALは「変更の連続した履歴」であり、ある基準点（フルバックアップ）に、その後のWALを順に適用すれば、後続の任意の状態を再構成できる——この性質こそがPITRの土台です。WALを下流へ流して別系へ反映する発想は、変更データキャプチャ（/devops/change-data-capture/）やレプリケーションと同根です。

ポイントインタイムリカバリ（PITR）：任意時点へ巻き戻す

PITRは「フルバックアップ（基準点）」と「それ以降の連続したWAL（変更履歴）」を両方保全し、復元時に基準点を展開してから、目標時刻までWALを再生して止める 仕組みです。

        フルバックアップ            目標復元時刻 T
            (基準点)                    │
   時間 ────●━━━━━━━━━━━━━━━━━━━━━━━━━━━│━━━━━━━━━━━━▶  現在
            └─────── WALを連続保全 ──────┘
                                        ▲
復元手順:
  1. フルバックアップ（基準点）を復元用サーバーへ展開
  2. アーカイブしておいたWALを時系列に適用（REDO）
  3. 目標時刻 T に対応するログ位置で適用を停止
  → T 時点と完全に一致した状態が再構成される

PITRの強力さは、基準点が古くても、WALさえ連続していれば任意の中間時刻へ正確に着地できる 点にあります。誤ったDELETEを流した「事故の1秒前」へ戻す、といった操作が可能になります。停止位置はログ位置・タイムスタンプ・名前付きのコミット境界などで指定でき、ログ列が途切れていなければ粒度はトランザクション単位まで細かくできます。

ここで注意すべきは、WALアーカイブが一つでも欠ければ、その先へはログを適用できず復元はそこで打ち止め になることです。連続性こそが命で、ログ列の保全は基準点の保全と同等以上に重要です。なお、複数ノードに分散したシステムでは「同一時点」の意味が単純でなく、ノードごとに時計と進行がずれるため、整合した全体スナップショットには因果順序を踏まえた調整が要ります（/devops/consistency-models/）。

3-2-1原則：相関故障からコピーを守る

整合したバックアップが取れても、それが障害と一緒に失われては意味がありません。3-2-1原則 は冗長配置の指針です。

3 : データのコピーを合計3つ持つ（本番＋バックアップ2つ）
2 : 異なる2種類の媒体／システムに保存する
1 : うち少なくとも1つはオフサイト（地理的に離れた場所）に置く

狙いは 相関故障の切断 です。本番と同じディスク装置、同じデータセンター、同じアカウントにバックアップを置けば、装置故障・火災・誤操作・アカウント侵害といった単一事象が、本番とバックアップを同時に巻き込みます。媒体を分け、場所を分けることで、一つの事象が全コピーへ波及する確率を下げる——リージョンをまたぐ災害対策（/devops/multi-region-failover/）と同じ「運命を共有させない」発想です。近年は、ランサムウェアや誤削除に備えて「1つは改変不能（イミュータブル）／オフライン」を加えた版もよく使われます。バックアップ自体が暗号化・削除されては元も子もないからです。

リストア検証：復元できないバックアップは無価値

最後に、最も見落とされ、最も重要な原則です——バックアップの成否は、実際に復元してみるまで不定 である。

よくある「成功しているのに復元できない」原因:
  - スナップショットが不整合（quiesceしておらず構造が壊れている）
  - WALアーカイブに欠落があり、目標時刻まで再生できない
  - バックアップは暗号化されているが、復号鍵を一緒に失っている
  - 復元手順が文書化されておらず、本番障害下で再現できない
  - 容量・権限・依存サービスの不足で復元先が立ち上がらない

これらはすべて、バックアップ取得時には一切エラーを出さない という共通点があります。ジョブは緑、容量も足りている。問題は復元側にしか現れません。だから定期的に 実際にリストアし、データが整合し、目標RPO/RTO内に立ち上がることを確認する 検証を運用へ組み込む必要があります。これは故意に障害を起こして回復力を測るカオスエンジニアリング（/devops/chaos-engineering/）の一形態であり、「復元できる」という前提を実測値へ変える行為です。

まとめ

• バックアップの目的はコピー作成ではなく「整合した状態への復元」。稼働中のディスクをそのまま写すと、メモリ上の未反映分を欠いた、あるいは時刻のねじれた 不整合な断面 になりやすい。
• 整合には段階がある。クラッシュ整合 は電源断相当でWAL系ならリカバリで自己修復でき、アプリ整合 はquiesce／フリーズでアプリ内バッファまで吐き出させた静止点。何が保証されるかは復元テストでしか確かめられない。
• WAL は「本体変更の前にログを先に書く」プロトコルで、REDO/UNDOによる復旧と、基準点＋変更履歴での再構成を可能にする。PITR はフルバックアップに連続WALを目標時刻まで適用して任意時点へ着地する。
• RPO の下限はバックアップ頻度ではなくWALアーカイブの転送間隔・連続性で決まり、欠落があればそこで再生は止まる。RTO は基準点の鮮度（再生量）に支配される。
• 3-2-1原則 は相関故障を断つ冗長配置（＋イミュータブル/オフラインで改ざん耐性）。だが最終防衛線は リストア検証 であり、定期的に実際に復元して整合と所要時間を実測しない限り、バックアップの成否は不定のままである。