Concepts
Changed block tracking (CBT)
How Datamotive uses hypervisor and cloud CBT mechanisms to identify changed disk blocks without reading entire disks.
- Product
- Datamotive Platform
- Version
- v2.0.3
- Last updated
- Updated
- Reading time
- 2 min read
Changed block tracking (CBT) is the mechanism that makes incremental replication efficient. Instead of reading every block on every disk during each replication cycle, Datamotive asks the hypervisor or cloud API which blocks have changed since the last cycle. Only those blocks are read and transferred.
CBT by platform
VMware vSphere
Datamotive uses the vSphere Changed Block Tracking API, which is part of the VMware Storage APIs for Data Protection (VADP). When CBT is enabled on a VM's disks, vSphere maintains a bitmap of changed sectors since the last snapshot.
At the start of each replication iteration, Datamotive takes a snapshot of the source VM (with Quiesce Guest OS enabled by default for application-consistent Windows snapshots), queries the CBT bitmap for changed blocks since the last checkpoint, reads only those blocks through the vSphere API, and then deletes the snapshot.
Requirements for vSphere CBT:
- Hardware version 7 or later (VMware VM hardware version, not vSphere version)
- The VM must not use physical RDM (pRDM) disks — these are not supported for protection
- VMware Tools must be installed in every protected VM
- The protection plan wizard prompts to Enable CBT on the selected VMs; the vCenter role needs the Toggle disk change tracking privilege
Amazon EC2
AWS EBS snapshots are incremental by nature: each snapshot stores only the blocks changed since the previous snapshot. Datamotive uses the EBS ListChangedBlocks API to identify changed blocks between two snapshot IDs, eliminating the need to read full snapshots.
Microsoft Azure
Azure Managed Disk snapshots support incremental snapshots. Datamotive uses the Azure Compute REST API to list page ranges changed between two snapshots, then reads only the changed pages.
Full transfers and resync
The first iteration for each disk always transfers full data (Type: Full in the Disks job view); later iterations are incremental. When incremental tracking is invalidated — or when you need to force a clean copy — use Edit plan → Resync Disk Replication to re-replicate entire disks (all VMs or selected ones, per disk). The sync status shows resync-in-progress until it completes.
Impact on source workload
CBT-based replication is read-only at the block level: Datamotive reads from snapshots, not from running disks, and removes the snapshot after each iteration. No agent or kernel module runs inside the guest VM. Per-VM replication scripts can hook before and after each snapshot when applications need custom quiescing — see Create a plan.
Related docs
Was this page helpful?
