The Short Answer
Changed block tracking (CBT) is a hypervisor-level mechanism that records which disk blocks have changed since the last backup, so an incremental backup reads only those blocks instead of scanning the entire disk.
The difference it makes is not subtle. Consider a 2 TB virtual disk with 1% daily churn: without CBT, every incremental still has to read all 2 TB to discover the 20 GB that changed; with CBT, the platform hands the backup tool a map and it reads 20 GB. CBT is the reason incremental-forever strategies are possible at all — without it, "incremental" only describes what gets written, not what gets read.
CBT on VMware vs CloudStack/KVM
On VMware vSphere, CBT is a native feature: the hypervisor maintains the change map per virtual disk, and backup tools query it through the storage APIs. On KVM — and therefore on Apache CloudStack — there is no platform-wide equivalent, so the backup vendor has to build change tracking itself, per storage path, and keep it consistent across every VM lifecycle event. That is why most backup products on CloudStack quietly fall back to full-image copies.
Sendense protects QCOW2/NFS, ZFS and Linstor/DRBD through agentless, CBT-enabled native paths; for other CloudStack block storage, its in-guest Universal Client maintains the changed-block map only — backup data always moves snapshot-driven from the hypervisor data layer, never through the client.
The operational caveat: trust, but verify the map
One caveat applies everywhere: change tracking can be invalidated — by storage migrations, certain snapshot operations, or crashes mid-cycle. A trustworthy backup platform detects invalid tracking data and falls back to a verified full read, rather than silently trusting a stale map; an incremental built on a wrong change map is corruption you won't discover until restore day.
FAQ
What is changed block tracking (CBT)?
Changed block tracking is a hypervisor-level mechanism that records which disk blocks changed since the last backup, so incremental backups read only those blocks instead of scanning the whole disk. It is what makes incremental-forever backup strategies practical.
Does CloudStack have changed block tracking?
Not natively. On CloudStack/KVM the backup vendor must supply change tracking itself. Sendense built agentless, CBT-enabled paths for QCOW2/NFS, ZFS and Linstor/DRBD; for other block storage its Universal Client maintains the changed-block map only, while backup data transfers snapshot-driven from the hypervisor data layer.
What happens if CBT data is lost or invalid?
The backup platform should detect invalid tracking and fall back to a verified full read of the disk. Trusting a stale change map produces incrementals that are silently corrupt and only discovered at restore time.