差分バックアップとは｜仕組み・増分との違いとRPO/RTOを踏まえた運用ベストプラクティス

差分バックアップとは

差分バックアップ（differential backup）は、「直近のフルバックアップ以降に変更・追加されたデータのみ」を保存するバックアップ方式です。フルバックアップはシステム全体のスナップショットを取得しますが、差分バックアップはそのフルバックアップとの差分だけを取り続けるため、フルと最新の差分さえあれば復元可能という特徴があります。

仕組みの詳細

一般的な運用では、まず定期的にフルバックアップを取得します（例：週に1回）。その後、日次で差分バックアップを取得すると、各差分バックアップは「そのフルバックアップ以降に変更された全データ」を含みます。したがって、差分バックアップは時間が経つにつれて大きくなり、次回フルバックアップを取得するまで増加し続けます。

• フルバックアップ：全データを保存（例：日曜日のフル）。
• 差分バックアップ：そのフルからの変更分を毎日保存（例：月〜土の差分）。
• 復元時：最後のフル + 最新の差分で復元可能。

差分と増分の違い

差分バックアップと混同されやすいのが増分バックアップ（incremental）です。主な違いは以下の通りです。

• 差分（differential）：フルバックアップ以降に変更された全てを毎回保存。復元はフル＋最新差分の2つで完了。
• 増分（incremental）：最後に取得したバックアップ（フルまたは増分）以降に変更されたデータのみを保存。復元はフル＋全ての増分チェーンを適用する必要がある。

結果として、差分は復元が単純（高速）で、増分は保存容量が小さくなる傾向があります（ただし、増分チェーンが長くなると復元時間が延びる）。

メリット・デメリット

差分バックアップを採用する際の主な利点と欠点を整理します。

• メリット
  • 復元手順が簡単：フルと最新差分の2つのみで復元可能。
  • フルを頻繁に取るよりはストレージ効率が良い（完全フルよりは容量を節約）。
  • フルバックアップ取得頻度を下げられるため、フルの負荷を軽減できる。
• デメリット
  • 差分は時間経過で大きくなるため、差分がフルに近いサイズになることがある。
  • バックアップウィンドウ（処理時間）が長くなりがち。
  • 差分バックアップが破損した場合は、最新差分が使えないと復元が困難になる。

実装上のポイント（技術的観点）

差分バックアップはファイルレベル（ファイル差分）とブロックレベル（ディスクブロック差分）のどちらでも実装可能です。用途やツールに応じて適切な方式を選択します。

• ファイルレベル差分：ファイルの更新日時やハッシュを使って変更ファイルを検出。一般的なファイルサーバーや個別ファイルのバックアップに適する。
• ブロックレベル差分：変更されたディスクブロック単位で差分を取得。仮想マシンやデータベースの大きなファイルに対して効率的。多くのスナップショット技術やクラウドのスナップショットはブロック単位で差分を扱う。

実例：

• Windowsの場合：VSS（Volume Shadow Copy Service）を用いたスナップショットでアプリケーション整合性を保ちながら差分を取得。
• Linuxの場合：LVMスナップショットや、rsyncの--link-dest（ハードリンクを用いた差分風の保存）などがある。
• クラウド：AWS EBSスナップショットは初回はフル、以降は増分（ブロック単位）として保存されるが、管理画面では差分/スナップショットとして扱われる。

運用設計：RPO、RTO、スケジュール、保存期間

バックアップポリシー設計ではRPO（許容データ損失時間）とRTO（目標復旧時間）が重要です。差分を採る頻度はRPOに依存します。

• 例1（一般的な構成）：週次フル + 日次差分 → 復元に必要なのは週次フル＋最新差分。中程度のRPO/RTOに適する。
• 例2（より短いRPO）：週次フル + 日次差分 + 日中は増分を利用（ハイブリッド） → 必要に応じて差分の粒度を調整。
• 保持期間（リテンション）：法令や業務要件に従い、世代管理（Grandfather-Father-Sonなど）で策定する。古い差分を自動で消す時はチェーンの整合性に注意。

検証とテスト

バックアップは取得して終わりではなく、定期的なリストア検証が必須です。ポイントは以下。

• 定期的に実際に復元テストを行う（データ整合性、アプリケーション起動確認）。
• バックアップファイルの整合性チェック（チェックサム、署名）。
• 暗号化・鍵管理のテスト：バックアップを暗号化している場合、鍵を失うと復元不能になるため鍵の保管・復旧手順を検証。

クラウドと差分バックアップ

クラウド環境では、バックアップの実装がサービス依存になります。たとえば、AWSのEBSスナップショットは内部的に増分で保存されますが、管理上はスナップショットを組み合わせて復元する仕組みです。クラウドのオブジェクトストレージに差分バックアップを保管する場合は、重複排除（deduplication）や圧縮を組み合わせることでコストを下げることが可能です。

ベストプラクティス

• フルバックアップと差分バックアップのバランスを決める（業務要件に基づく）。
• 差分が大きくなる前に定期的にフルバックアップを取得する（例えば週次や月次）。
• バックアップチェーンの監視とアラートを実装し、失敗や壊れを即検知する。
• 暗号化・アクセス制御を適用し、バックアップデータの機密性を担保する。
• 定期的なリストア検証とドキュメント化（手順書を最新化）。

注意点・落とし穴

• 差分のサイズ肥大：フルからの差分が大きくなった場合、差分の取得に時間とストレージを要する。
• チェーン破損リスク：差分ファイルやフルが破損したときの影響範囲を明確にしておく。
• アプリケーション整合性：データベースなどはアプリケーション整合性を保つためにログバックアップやVSS等を併用する必要がある。
• 法令遵守・保管場所：保存先（オンプレ/クラウド/海外）の法的制約を確認する。

まとめ

差分バックアップは「フル以降のすべての差分を保存する」ことで復元手順を単純化できる手法です。増分バックアップと比べて復元が速く、運用が分かりやすい反面、時間とともに差分が大きくなる点に注意が必要です。実運用ではRPO/RTOに合わせてフルと差分・増分を組み合わせたり、スナップショットや暗号化、検証プロセスを組み込むことが重要です。

参考文献

• 差分バックアップ - Wikipedia（日本語）
• Microsoft Docs - SQL Server のバックアップと復元（日本語）
• Amazon EC2 ユーザーガイド - EBS スナップショット（日本語）
• Red Hat - LVM スナップショット（日本語ドキュメント）
• Veeam Blog - Difference between full, differential and incremental backups
• Rsync を使ったハードリンク方式のバックアップ（Arch Wiki、英語）