Veeam は、2006年にスイスで誕生したデータ保護ソリューションの企業です。当初は VMware 専用のバックアップソフトとして一世を風靡し、現在は「Veeam Data Platform」として、物理サーバ、クラウド（AWS/Azure/GCP）、SaaS（Microsoft 365/Salesforce）など、あらゆる環境をデータ保護可能な統合管理プラットフォームへと進化しています。

本記事では、バックアップデータの世代管理の基本動作について、情報共有したいと思います。検証環境、バックアップ時のデータサイズなどについては、初回記事にて紹介していますので、そちらを参照してください。
Veeam ホットアド構成のバックアップ

今回は、”Retention policy” が 7days なのに、バックアップデータが曜日によって8個以上も保持されているといった事象に対して理由を知りたい方向けです。

バックアップデータの世代設定

バックアップジョブを新規作成した際、デフォルト設定におけるバックアップデータの世代数は「7日分」です。「7個」ではありません。あまりないケースですが、24時間以内に複数回のバックアップを取得した場合、 Veeam Backup & Replication におけるバックアップデータ数は「1日分」のカウントとなります。

バックアップデータの世代数の設定は、バックアップジョブの中の “Storage” ⇒ “Retention policy” にあります。

図：Retention policy

また、デフォルト設定では、バックアップデータの世代数に影響を与えるオプション機能として、”Create synthetic full backups periodically” があります。この機能は、増分バックアップのチェーンが長くなりすぎるのを防ぎ、データの健全性を保つものです。デフォルトでは毎週土曜日に起動します。既存の増分バックアップデータ（拡張子 .vib）を繋ぎ合わせて、最新のフルバックアップデータ（拡張子 .vbk）を合成作成します。

このオプション機能の設定は、バックアップジョブの中の “Storage” ⇒ “Advanced Settings” ⇒ “Backup タブ” ⇒ “Create synthetic full backups periodically on:” にあります。

図：Create synthetic full backups periodically

ジョブの実行状態と世代

デフォルト設定で、仮に土曜日からバックアップジョブを実行した場合、まずフルバックアップが取得されます。翌日以降は増分バックアップが続きます。”Retention policy” が 7days のため、フルバックアップのデータを含めて最大7日分のバックアップデータが保存されます。言い換えると下図の①から⑦の7世代目まで保存されます。

図：”Retention policy” が 7days の世代

本来、土曜日は、”Create synthetic full backups periodically on: 土曜日” の設定に従って、それまでの増分バックアップデータとフルバックアップデータを合成して、フルバックアップを生成する曜日です。上記の例では、土曜日にフルバックアップを開始したため、”Create synthetic full backups periodically on: 土曜日” が起動していません。
この状態で一週間後の土曜日を迎えるとどうなるでしょうか。

図：”Create synthetic full backups periodically on: 土曜日” が完了した状態

Veeam Backup & Replication は、”Create synthetic full backups periodically on: 土曜日” の設定に従って、土曜日にそれまでの増分を単一のフルバックアップデータに合成します。これが1世代目（①）のバックアップデータとしてカウントされます。”Retention policy” が 7days に従って、前週日曜日の7世代目までが保持できればいいのですが、この場合、前週土曜日と翌日曜日の2日分が7世代目（⑦）として保持されます。

7日分だからバックアップデータは常時7個では？と思われるかもしれませんが、上記例では、計8個のバックアップデータが残っている状態になります。これは、前週日曜日の増分の状態をリストアするためには、前日の土曜日のフルバックアップが必要なためです。そのため、前週土曜日のフルバックアップデータと、日曜日の増分データの2つのファイルが、7世代目（⑦）としてセットでカウントされているのです。

同様の理由でこのセットは翌週の金曜日まで継続します。つまり、翌週の金曜日のバックアップ完了時には14個のバックアップデータが保持されることになります。この時点が “Retention policy” 7days で最大保持されるバックアップデータ数になります。その翌日の土曜日の合成フルバックアップが完了すると、前週の8個のバックアップデータがセットで削除されます。

なお、土曜日の合成フルバックデータから金曜日までの増分バックアップデータのセットのことを、バックアップのチェーンと呼び、このチェーンが必要とされなくなるまで、過去のバックアップデータは残り続けることになります。チェーンの起点がフルバックアップ（または合成フルバックアップ）にあると理解すると簡単かもしれません。

以上から、1回あたりの増分バックアップデータのサイズが巨大になることが予想される場合、”Retention policy” が 7days として、最大時は合成フルバックアップx2個、増分バックアップx12個となるサイジングを行いましょう。無論、”Retention policy” の数値を大きくした場合は、さらにサイジングに注意を払う必要があります。

増分と差分の違い

Veeam Backup & Replication は、フルバックアップ後のバックアップにおいて「増分（Incremental）バックアップ」方式を採用しています。差分（Differential）ではありません。
一般的なバックアップにおける増分と差分の違いを以下に示します。

■増分

方式：直前のバックアップ時点からの変更・追加データだけを数珠つなぎで記録する方式。
メリット：毎日のデータ量が小さく、バックアップ時間が短い。ストレージ（リポジトリ）容量を節約可能。
デメリット：復元時に時間がかかる。途中の世代のデータが壊れるとデータ復元ができない。

■差分

方式：最初のフルバックアップ時点からの変更・追加データを毎回すべて重複して記録する方式。
メリット：復元が高速。復元時に必要なデータ（世代）は「フル＋最新の差分」の2つだけ。
デメリット：日数が経過するほどデータ量が肥大化し、バックアップ時間が長くなっていく。ストレージ容量を多く消費する。

増分のデメリット解消

Veeam Backup & Replication では、増分バックアップにおけるデメリット解消のために、3つの機能を有しています。

①合成フルバックアップ
本記事で触れている機能です。バックアップ先ストレージ（リポジトリ）の内部だけで、既存の「古いフル」と「日々の増分」を合体（マージ）させ、新しい1つのフルバックアップ（.vbk）を生成します。これにより、短い「増分チェーン」を定期的に作り直すことにより、途中の世代のデータ破損による復元エラーや、復元時間の短縮を実現しています。

②逆方向増分バックアップ
通常の増分は「古いフル ＋ 日々の増分（未来へ向かう）」という構造ですが、逆方向増分では、バックアップが実行されるたびに、最新の状態を「フルバックアップ（.vbk）」として上書き・生成します。バックアップ先ストレージ（リポジトリ）上にある最新のバックアップデータが常に「フルバックアップ」そのものになるため、増分ファイルを1個も繋ぐことなく、1回で復元が完了します。

③ヘルスチェック機能
「途中の増分データが1つでも壊れたら、それ以降が全滅する」という増分最大の問題を解消するためのメンテナンス機能です。ジョブのスケジュール設定で「Health check」を有効にしておくと、Veeam は定期的に（月に1回など）、バックアップストレージ（リポジトリ）内のチェーンを構成するすべてのファイル（.vbk や .vib）のデータ構造を自動でスキャンします。もし内部でデータが壊れているものを見つけた場合、次のバックアップ実行時に、その壊れている部分のデータだけをバックアップ対象から再取得して修復します。

以上となります。次回は、復元（リストア）の動作実際について共有予定です。

Veeam Backup & Replicationが分かる！使える！実践できるデータ保護のすべて