増分バックアップとは｜仕組み・種類（差分/インクリメンタル）比較、復元手順と実運用のベストプラクティス
エバープレイ編集部増分バックアップとは
増分バックアップ（ぞうぶんバックアップ、incremental backup）は、前回のバックアップ以降に変化したデータだけを保存するバックアップ方式です。フルバックアップがすべてのデータを毎回保存するのに対し、増分バックアップは差分のみを取り、ストレージ容量と転送時間を節約します。ただし、復元時には適切なバックアップチェーン（フル＋増分の連鎖）を辿る必要があり、運用設計と検証が重要です。
基本的な働き・種類
- 従来型増分（incremental）：直前のバックアップ（フルまたは前の増分）以降に変更されたデータだけを取得。復元時は初回フル＋すべての増分を順に適用する必要がある。
- 差分（differential）：最後のフルバックアップ以降に変更されたデータすべてを取得。復元は最後のフル＋最新の差分だけで済むため、復元時間は短縮されるが、差分は時間経過で大きくなる。
- インクリメンタル・フォーエバー（incremental-forever）：初回フル以降は全て増分で運用し、サーバ側で合成（synthetic full）したり、必要時に合成して「仮想フル」を作る方式。クラウドバックアップや一部商用製品で採用される。
技術的な実装方式
- ファイルレベル増分：ファイルの更新日時やハッシュを基に、変更したファイルを丸ごと保存。小規模なファイル数が多い環境に向くが、大きなファイルの一部変更でも全体をコピーする。
- ブロックレベル増分：ディスクやイメージを固定ブロックに分割し、変更があったブロックだけを保存。大きなファイルの一部更新でも効率が良い。仮想マシンやデータベースのバックアップで多用される。
- 変更トラッキング（Change/Changed Block Tracking）：OSやハイパーバイザがどのブロックが変更されたかを記録する機能（例：VMware CBT）。これを利用すると増分バックアップがより正確かつ高速になる。
- スナップショットベース：ファイルシステムやクラウドのスナップショット機能を利用し、スナップショット差分を取得。例：AWS EBSスナップショット、ZFSスナップショット。
利点と欠点
- 利点
- ストレージとネットワーク使用量の削減（フルを毎回取得するより効率的）。
- バックアップウィンドウ（実行時間）の短縮が期待できる。
- クラウド環境や遠隔バックアップで帯域とコストの節約に有効。
- 欠点
- 復元はフル＋増分チェーンに依存するため、復元時間（RTO）が長くなる可能性がある。
- 増分チェーンが壊れる（欠損や破損）と復元不能になるリスクがある。
- 管理が煩雑になりやすく、検証（リストアテスト、整合性チェック）が重要。
復元の流れとリスク管理
増分バックアップからの復元は一般に次の流れです：まずベースとなるフルバックアップを復元し、その後、時系列で増分を順に適用して目的の時点に戻します。差分方式なら最後の差分だけを適用すればよい点が異なります。
増分方式のリスクはチェーン依存性です。増分ファイルの欠損や破損があると、それ以降の復元ができなくなります。対策としては定期的なフル取得、合成フル（synthetic full）の実施、チェーンごとのチェックサム検証、そして定期的なリストアテストが必要です。
実運用での考慮点（RPO/RTO、世代管理、保持ポリシー）
- RPO（Recovery Point Objective）とRTO（Recovery Time Objective）を設計に反映する。増分はRPOを小さくできるが、RTOは増分数に比例して伸びる可能性がある。
- 世代管理（Retention）：どの時点のバックアップをどのくらい保持するかを決める。GFS（Grandfather-Father-Son）などのポリシーを組み合わせることが多い。
- 合成フル vs 定期フル：合成フルはストレージ側で増分を結合してフルを作成するため、転送コストを抑えつつフルを保持できるが、サーバ負荷と整合性管理が必要。
アプリケーション整合性とトランザクション性
ファイルコピーだけでは整合性が取れないデータベースやメールサーバなどでは、アプリケーションに対する「アプリケーション整合性（application-consistent）」なバックアップが必要です。これには以下が含まれます：
- アプリケーションのクエスチェンジ（一時停止）やトランザクションログのフラッシュ。
- OSレベルのボリュームスナップショットとアプリケーションのVSS（Windows Volume Shadow Copy Service）連携。
- データベース専用の増分方式（例：Oracle RMANの増分バックアップやSQL Serverの差分バックアップ／トランザクションログバックアップ）。
実例とツール
- rsync/rsnapshot：rsyncの差分転送とハードリンクを活用して増分風の世代管理を行う。小〜中規模ファイルのバックアップで汎用的に利用される。
- restic / Borg / Duplicity：スナップショット方式と重複排除（dedup）を備え、暗号化と増分での効率的な保存を提供するオープンソースのバックアップツール。
- Veeam / Commvault / Veritas：商用バックアップ製品で、VMやデータベースの増分・CBT・合成フルなど高度な機能を提供。
- クラウドのスナップショット：AWS EBSスナップショットは変更ブロックのみを保存するインクリメンタル設計。Azure Managed Disk SnapshotsやGoogle Cloud Persistent Diskのスナップショットも同様の概念を持つ（ただし実装詳細は各社異なる）。
設計と運用のベストプラクティス
- 初回は必ずフルバックアップを取得し、その後増分を取得する運用を明確にする。
- 定期的にフルバックアップを取得するか、合成フルを作成してチェーンの長さを制限する。
- バックアップファイルに対するチェックサム検証、整合性チェック、暗号化を実施する。
- バックアップの保管場所を分離（オンサイトとオフサイト、あるいは異なるクラウド）し、災害対策を行う。
- 自動化されたリストアテストを定期的に行い、実際に復元できることを確認する。
- バックアップ対象の変更トラッキング（CBT）やアプリケーション連携（VSSやDB専用API）を有効活用する。
- 暗号化とアクセス管理でバックアップの機密性を担保する。特にクラウド保管時は鍵管理に注意。
よくある誤解
- 「増分＝常に安全で容量的に最小」：増分は効率的だが、長期間放置した増分チェーンは管理が難しくなるため、必ずしも最小の容量運用になるとは限らない。
- 「クラウドスナップショットは常に完全」：多くのクラウドベンダーのスナップショットは内部的に増分保存を行うが、スナップショットの整合性やリストア手順、課金体系は各社で異なるため仕様の理解が必要。
まとめ（チェックリスト）
- 初回フル＋増分で運用、復元手順を明確に。
- 増分チェーンの定期的なフル統合または定期フル取得を計画。
- アプリケーション整合性（VSSやDB専用API）を確保。
- バックアップの整合性検証とリストアテストを自動化。
- 保持ポリシー、暗号化、オフサイト保持を含む総合的なバックアップ戦略を策定。
参考文献
- Wikipedia: Backup (英語)
- AWS: Amazon EBS スナップショット（公式ドキュメント）
- Microsoft: Volume Shadow Copy Service (VSS)
- VMware: Changed Block Tracking (CBT)（vSphere ドキュメント）
- restic 公式サイト
- BorgBackup 公式サイト
- Veeam 公式サイト
投稿者プロフィール
