バックアップソースのVMで実験的な変更を加える際、変更前にスナップショットを取得することは運用上あるかと思います。さらに実験的な変更が思わしい結果にならなかった場合、スナップショットをロールバックすることもあると思います。さて、この変化をバックアップする VBR は Proxmox VE の VM で認識することができるのか？というのが今回の検証内容です。

技術的に言い換えると、「バックアップ対象のデータが意図せず過去に戻ったとき、VBR の CBT（変更ブロック追跡機能）が、Proxmox VE の QEMU と連携して、正しく処理できるのか、それとも何も変わっていないとスルーしてしまうのか」を検証します。

本記事の検証構成

全てを Proxmox VE 上で構成しています。VM である Windows Server 上の VBR は、ローカルリポジトリを含めたオールインワン構成とし、バックアップ対象の RockyLinux も同じく VM です。
VBR がバックアップとリストアを行う時は、Proxmox VE の API 経由で QEMU や KVM と通信します。

CBT について

詳細は別の技術サイトの解説に譲り、概要だけ説明します。

必要な技術要素として、Block（ブロック）が挙げられます。Block は HDD や SSD、仮想マシンのディスク（ VMDK や QCOW2 など）がデータを読み書きする際の最小のデータ単位です。環境によって異なりますが、一般的には 4KB、64KB、あるいは数 MB 単位で区切られています。ファイルや OS のデータは、この Block という「箱」に分割されて保存されます。

次に Bitmap（ビットマップ）です。各 Block が「変更されたか（Dirty）」、あるいは「未変更か（Clean）」という状態を 0 と 1 の1ビットのデジタル信号で表した一覧表です。Bitmap 自体にはファイルの内容（実データ）は含まれません。あくまで「○番目の Block は変更された」というフラグ情報だけを保持しています。

この Bitmap を利用して Block 単位で変更ブロックの追跡を行うのが、CBT（変更ブロック追跡）機能となります。

VBR の CBT 機能は、Proxmox の API 経由で、バックアップ時に Bitmap をもとにバックアップすべき Block を吸い上げて、バックアップ先のリポジトリに Block data（変更された実データ）と Bitmap data（変更の一覧表）を保存します。増分バックアップ時は、Proxmox VE が保持する Bitmap をもとに変更が発生している Block data だけを特定し、VBR がそれを吸い上げるという仕組みです。

一方、Proxmox VE では、VM（仮想マシン）のディスクが QEMU/QCOW2 により Block 単位で管理され、スナップショット機能も同様に Block 単位の差分管理で動作します。

つまり、バックアップ用の CBT と、スナップショット用の CBT は独立した別の仕組みで動作しています。

検証したいこと

Proxmox VE で、スナップショットを以前の状態に戻す（ロールバックする）と、VM のディスク状態が過去に書き換わるため、ロールバック後に VBR が増分バックアップで参照する Bitmap が、実際のディスク状態と一致しなくなるという問題が懸念されます。

万が一、VBR がこの状態を認識できなかった場合、実データと Bitmap の時間軸がズレているにもかかわらず、そのまま増分バックアップが実行されてしまいます。その結果、バックアップデータ内に不要な Block と本来必要な Block が混在することになり、将来的にそのバックアップからリストアを試みても、正常に動作しない（システムが起動しない、データが破損している）といった深刻な事態を招く可能性があります。

検証ステップ

以下のステップで検証を実施します。重要なステップは⑥の3回目の増分バックアップであり、これが正常に取得できないと、以後のバックアップファイルは正常なデータではなくなります。

①ソースVMのスナップショットを生成（＝過去のセーブポイントを作る）
②VBR で1回目のフルバックアップを取得（＝スナップショット時点のバックアップ完了）
③ソースVM上に「1ファイル」を増やして保存
④VBR で2回目の増分バックアップを取得（＝ファイルがある状態を保存）
⑤Proxmox VE で、①で取得したスナップショットにロールバック（時間の逆行）
※VM 内から「1ファイル」が消滅し、OS の時刻や Block の実データが、②の時点に逆行します。
⑥逆行した状態で VBR で3回目の増分バックアップを実行【検証の核心】
⑦ ⑥で取った3回目の増分バックアップを別名でリストアし、中身を確認

⑦における VBR が正しく処理された場合の期待結果は、リストアされた OS が 1ファイルを増やす前の、初回スナップショット直後の状態になることです。2回目の増分バックアップの状態になったり、OS が正常起動しなかったりした場合は、VBR がスナップショットのロールバックを認識できないという結論になります。

検証の実行

①ソースVMのスナップショットを生成（＝過去のセーブポイントを作る）

まず、テストファイルを設置予定の /root 以下が1ファイルのみであることを確認します。

# pwd
/root
# ls
anaconda-ks.cfg

次に Proxmox VE でソース VM の初回スナップショットを取得します。スナップショット取得時刻は 18:40:17 です。なお、スナップショットはソース VM が起動状態で取得しました。

②VBR で1回目のフルバックアップを取得（＝スナップショット時点のバックアップが完了）

バックアッププロセスの “Read” サイズが VM のディスクサイズである 50GB でしたのでフルバックアップと判断できます。バックアップ取得時刻は 18:58:37 です。

③ソースVM上に「1ファイル」を増やして保存

ファイル作成時刻は 19:10 です。

# pwd
/root
# touch test.txt
# ls -ls
合計 4
4 -rw-------. 1 root root 1422 11月  1  2025 anaconda-ks.cfg
0 -rw-r--r--  1 root root    0  7月  4 19:10 test.txt

④VBR で2回目の増分バックアップを取得（＝ファイルがある状態を保存）

バックアッププロセスの “Read” サイズが、変更があった Block サイズと思われる 122MB と極小でしたので増分バックアップが実行された判断できます。バックアップ取得時刻は 19:30:24 です。この増分バックアップには③で追加した “test.txt” が含まれていることになります。

⑤Proxmox VE で、①で取得したスナップショットにロールバック（時間の逆行）

これによりソース VM から “test.txt” が消滅し、OS の時刻や Block の実データが、②の初回スナップショット直後の時点（18:40:17）に逆行します。

ソース VM の状態を確認します。date コマンドの結果が 18:41:16 となっているため時間が逆行したことがわかります。また、③で追加した “test.txt” も消滅しています。

# date
2026年  7月  4日 土曜日 18:41:16 JST
# pwd
/root
# ls -ls
合計 4
4 -rw-------. 1 root root 1422 11月  1  2025 anaconda-ks.cfg

⑥逆行した状態で VBR で3回目の増分バックアップを実行【検証の核心】

いよいよ、VBR で3回目のバックアップを実行します。”Read” サイズがディスクサイズの 50GB となったため、フルバックアップに切り替わったのかと思いましたが、”Transferred” サイズは 41.5MB ですので、増分バックアップが実行されているように見えます。バックアップ取得時刻は 19:52:06 です。

バックアップファイルを参照すると、やはり3回目も増分が実行されていました。

⑦ ⑥で取った3回目の増分バックアップを別名でリストアし、中身を確認

果たして VBR は2回目の増分バックアップからの差分を3回目として取得してしまったのか（ロールバックに気が付かず通常の2回目の Bitmap と思って差分をとってしまうのか）、何らかのトリガーによって賢く動いているのか、どうでしょうか。

結果を見るため3回目の 19:52:06 の増分バックアップを指定してリストアします。

リストアされた VM は停止状態のため、起動します。まず、時刻を確認します。

3回目の増分バックアップ取得時刻の 19:52:06 ではありませんでした。これは VM 起動時に仮想ハードウェアクロックの時刻を読み取って OS が起動したためと想定できます。スナップショットのロールバック時は OS 起動状態で date が打てますので、時間の逆行が明確に確認できましたが、リストアだと起動時に時刻が修正されてしまうため、時刻観点での確認ができないことに気がつきました。

# date
Sat Jul  4 08:54:21 PM JST 2026

次に “test.txt” の確認です。

# pwd
/root
# ls -ls
total 4
4 -rw-------. 1 root root 1422 Nov  1  2025 anaconda-ks.cfg

消滅しています。これは3回目の増分バックアップが2回目の増分バックアップを反映していないことを裏付けする結果と判断できます。

最後にリストアした VM の message ログを確認してみます。

# grep -E "Jul  4 18:" /var/log/messages | wc -l
1736
# grep -E "Jul  4 19:" /var/log/messages | wc -l
0
# grep -E "Jul  4 20:" /var/log/messages | wc -l
1362
# grep -E "Jul  4 21:" /var/log/messages | wc -l
104

19:00 台のログが欠損しています。

時系列をまとめます。

18:40:17 初回スナップショット取得時刻

18:58:37 初回フルバックアップ取得時刻

19:30:24 2回目の増分バックアップ取得時刻

初回スナップショットにロールバック実行

19:52:06 3回目の増分バックアップ取得時刻

20:48:17 3回目の増分バックアップのリストア完了時刻

VBR が3回目の増分バックアップ時に、何らかの理由により2回目の増分バックアップの Bitmap が異常であることを見抜いて、スナップショット直後の初回フルバックアップをベースラインとして増分バックアップしたのであれば、18:00 台にログ出力があり、19:00 台にログ出力がなく、20:00 台にログ出力があることは論理的に正しいものと考えられます。

リストア後の VM のそのほかのログや、DB を含めたアプリケーションの動作を確認しても正常であることから、3回目の増分バックアップが、Proxmox 側のスナップショットのロールバック後であったとしても、正常に行われたものと判断できます。

考察

以下は、今回の VBR の挙動に対する推察となります。

VBR は3回目の増分バックアップ開始時、Proxmox VE に対して「前回（2回目）のバックアップ時点からの変更ブロック（dirty-bitmap）をください」と要求を出しましたが、Proxmox VE では「スナップショットのロールバック」が実行されたことで、QEMU プロセスが管理していた「2回目以降の変更を記録した Bitmap 」が無効化されていたため、Proxmox VE は VBR に対して「 Bitmap データは使用不可（または存在しない）」と回答し、VBR の CBT 機能は「 Bitmap が壊れた」と認識したものと考えられます。

これを受けて VBR は全セクターをスキャンするフォールバック処理に切り替わり、VM のディスクサイズとなる50GB をフルスキャンして全 Block のハッシュを計算します。そのハッシュを、リポジトリにすでに保存されている過去のバックアップ（1回目と2回目）のハッシュと突き合わせます。
すると、「現在のディスクのブロックは、1回目のフルバックアップのブロックとほぼ完全に一致する。2回目の増分（未来のファイル）のブロックは存在しない」と自力で気がつけるはずです。

結果として、「すでにリポジトリにあるデータ（1回目のブロック）をベースとして使えばいいから、ネットワーク越しに送る必要はない」と判断し、わずかなメタデータや OS の差分である 41.5 MB だけを送信し、増分ファイル（.vib）として保存したものと想定できます。

ロールバックによる Bitmap の無効化をトリガーにフルスキャンし、変更 Block を的確に検知し、さらに初回フルバックアップ同様に全 Block data をリポジトリに再転送しないところが VBR の賢い点でもあります。

以下は、Veeam の文献からの抜粋です。今回はスナップショットのロールバックがトリガーでしたが、VM や Proxmox VE の予期せぬ電源断においても、Bitmap が無効化されるケースがあることが示唆されています。この場合でも、フルスキャンしつつ増分バックアップのタイミングであれば賢く変更 Block data のみをリポジトリに転送するものと思われます。

参考：Limitations for Changed Block Tracking

Due to Proxmox VE technical limitations, bitmaps created for disks in the RAW and VMDK formats are automatically removed as soon as VMs that have these disks attached are powered off or restarted. Therefore, Veeam Backup & Replication may not be able to use CBT when processing those VMs and trying to detect data blocks that have changed since the previous backup session. If CBT cannot be used, Veeam Backup & Replication reads the whole content of VM disks and compares it with backed-up data that already exists in backup repositories. In this case, it may take Veeam Backup & Replication more time to create incremental backups.

QEMUプロセスの正常性維持 変更点を記録する dirty-bitmaps は QEMU プロセス（メモリ上など）で管理されているため、VM やホストが強制終了（予期せぬ電源断）した場合は、追跡情報がクリアされる場合があります。その場合、次回のバックアップは全セクターをスキャンするフォールバック処理に切り替わります。

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