What is Changed Block Tracking (CBT) and How Does it Speed Up Incremental Backups?

Changed Block Tracking (CBT) is a feature of the virtualization or storage layer that records which blocks of a virtual disk have changed since a reference point, such as the previous backup. Backup software asks for that list and reads only those blocks, instead of scanning the entire disk to find differences. The speed-up is conditional: it depends on how much data changes, how fine the tracking is, and whether the tracking state is still intact.

Key Takeaways

• CBT answers "what changed," not "what to store." It reduces reading and transfer; deduplication and compression are separate steps that reduce what is stored.

• Tracking happens outside the guest OS. The virtualization or storage layer notes which blocks are written, so nothing needs to run inside the VM just to track changes.

• Every major platform has its own version of the idea. The concept is the same everywhere, but names, storage of the tracking data, and limits differ; the platform comparison below covers the differences.

• Tracking state can be lost. A power failure, a stopped VM, or a mode change can force a slower fallback scan on the next run.

• Size your backup window for the fallback scan, not the average incremental. This is the most common planning gap.

What is Changed Block Tracking?

CBT is a change log for virtual disk blocks. It does not copy data. It only records where data was written, so a backup application can ask "which areas changed since backup X?"

A disk is divided into many small blocks. CBT keeps a record, usually a compact map, of which blocks have been written since a chosen reference point, typically the last backup. The backup tool uses that record to decide what to copy, so it never has to examine blocks that stayed the same.

CBT is not a backup type and not a copy of your data. It is the change record that makes a block-level incremental backup efficient. Different platforms use different names and implementations for it; the platform comparison later in this article covers them.

Notice: There are different names used on different platforms.

How Does CBT Work?

CBT keeps a running list of which parts of a virtual disk have been written to. At the next backup, the backup tool reads only the parts on that list, then starts a fresh list for the following round.

An everyday analogy: Imagine a shared 1,000-page manual. Instead of re-reading every page to find edits, you put a sticky note on each page whenever someone changes it. At review time, you copy only the flagged pages, then remove the notes and start again. CBT does the same for disk blocks.

The cycle in five steps:

1. Set a starting point. The first full backup copies the disk and marks a reference point, so the tracker knows "changes are counted from here."

2. Record every write. While the VM runs, the virtualization or storage layer notes which blocks are written. It records the location of each change, not the data itself, and it does this outside the guest operating system.

3. Ask what changed. At the next backup, the tool asks the platform for the blocks changed since the reference point.

4. Copy only those blocks. Everything else is skipped without being read.

5. Move the starting point forward. The new backup becomes the reference point, and the cycle repeats.

QEMU's upstream documentation describes this same idea as tracking which sections of a disk the next incremental backup needs to copy, and notes that an incremental taken from an empty tracking record copies nothing, as if nothing changed.

Why the reference point matters: the change list only means something relative to a specific starting point. If that link is broken, for example because tracking was reset, the tool can no longer trust the list and must fall back to reading and comparing the whole disk.

Why Does CBT Make Incremental Backups Faster?

Without change tracking, the backup tool must read the disk and compare it to the previous backup to learn what changed. CBT replaces that comparison with a lookup.

The saving comes from skipping work: blocks that did not change are never read, compared, or sent.

What CBT shortens:

• Source reads: unchanged blocks are never read.

• Network transfer and target writes: only changed blocks travel.

• Comparison work: no full-disk checksum pass is needed.

What CBT does not shorten:

• The first full backup.

• Snapshot creation and removal.

• Restore time, which still depends on how the backup chain is stored.

Gains are largest for big disks with a low change rate, such as file servers and archives. They shrink when most blocks change between runs. Actual speed depends on storage, network, backup software, and workload, so no universal speed-up figure applies.

When Should You Rely on CBT?

Which Change-Detection Method Should You Use?

Use this matrix when your platform or backup product offers more than one option.

Troubleshooting Table

Best Practices

• Verify in job logs that tracking was actually used after every platform upgrade or job change.

• Keep VMware VMs snapshot-free when enabling CBT.

• Avoid changing incremental modes on production jobs without budgeting for a full backup.

• Measure several real incremental cycles per workload; do not forecast from file-level change rates.

• Run restore tests. PBS documentation recommends regular backups together with restore tests, and CBT does not validate restorability.

FAQs

Q1: Can CBT back up a powered-off VM?

It depends on the platform. In the VMware API, omitting the snapshot parameter computes changes against the "current" snapshot, which Broadcom says works only for powered-off VMs. On Proxmox VE, the dirty bitmap lives in the running QEMU process, so a stopped VM does not benefit from it.

Q2: Can I enable CBT on a VM that already has snapshots?

Broadcom advises no snapshots when enabling CBT. Snapshots that predate CBT lack change IDs, which can trigger the `Unknown change epoch` fault.

Q3: Does CBT replace deduplication?

No. CBT decides what to read; deduplication decides what to store. Proxmox Backup Server uses both: backups are sent incrementally and deduplicated on the server.

Q4: Is each incremental backup a full backup when restoring?

That depends on how the product stores them. In Proxmox Backup Server, every snapshot references all chunks and is therefore a full backup, even though upload is incremental. Chain-based products behave differently, so check how yours restores.

Q5: What happens if I change the incremental mode of an existing backup job?

Expect the next run to be a full backup. In Vinchin Backup & Recovery, for example, the documentation states that changing the incremental mode (CBT, SpeedKit, or ordinary incremental) downgrades the next incremental to a full backup. Other products may behave differently, so schedule mode changes with a full backup in mind.

Q6: Does CBT expose my data?

The tracking structure records which regions were written, not their contents. QEMU describes its bitmaps as tracking which sections of a file to copy. Backup data itself is still protected through your normal backup security controls.

Q7: How do I know my incremental really used CBT?

Check the job log of your backup product; wording varies. A first run after enabling is always a full read, and a small second run relative to disk size is the usual sign.

Conclusion

CBT moves the cost of an incremental backup from scanning the whole disk to reading only what changed, but the saving is conditional. It holds while tracking state stays intact and writes stay localized. Size the backup window for the fallback scan, verify tracking in job logs after every platform change, and test restores regularly.