Changed block tracking (CBT)

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 cycle, Datamotive takes a quiesced or crash-consistent snapshot of the source VM, 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 RDMs in physical compatibility mode
• CBT is automatically enabled by Datamotive when a VM is added to a plan

Nutanix AHV

Datamotive uses the Nutanix Changed Region Tracking API. This API returns the list of dirty byte ranges on each vDisk since a given snapshot ID. The Datamotive Replication Appliance queries this API at the start of each cycle.

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.

What happens if CBT is reset

A CBT reset occurs when the hypervisor loses the change bitmap, typically after a VM migration, a hardware change, or enabling CBT for the first time. When a CBT reset is detected, Datamotive automatically falls back to a full rescan for that replication cycle. The next cycle resumes using incremental tracking.

Frequent CBT resets indicate an unstable environment and may cause RPO drift due to the larger data transfer. Investigate the cause (vMotion frequency, VM hardware changes) if resets occur more than once per week.

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 cycle. The impact on source VM performance is:

• A brief I/O pause when the snapshot is created (typically under 2 seconds for quiesced snapshots)
• Additional vSphere API calls to create, query, and delete the snapshot
• No agent or kernel module running inside the guest VM

Related docs

• Replication engine

• Block transfer

• Supported environments

• Run replication