Changed Block Tracking limits after a VM restore from a VADP backup

Direct answer

vSphere does not automatically clear Changed Block Tracking (CBT) state when a VM is restored from a VADP backup. The CBT metadata (.ctk files and the per‑disk changeId) can survive the restore and become out‑of‑sync with the restored disk contents. Consequently, the first incremental backup after a restore is not guaranteed to be complete or consistent unless the backup software forces a full backup or explicitly resets CBT before resuming incrementals.

Confirmed facts vs. likely explanation

Confirmed facts

• CBT state is stored per virtual disk as CTK metadata and a changeId that VADP backup agents read via QueryChangedDiskAreas.
• VMware documentation states that CBT is not automatically reset by a restore operation; the backup application is responsible for managing CBT state.
• PowerCLI can expose the current CBT enablement and changeId for each hard disk (Get-VM | Get-HardDisk → ExtensionData.Backing.ChangeId and the VM advanced setting ctkEnabled).

Likely explanation

When a restore replaces a virtual disk (full VM restore, disk re‑attach, or storage‑snapshot‑based restore), the newly presented disk may retain the old .ctk file if the backup process copies it, or the VM configuration may retain the ctkEnabled flag. If the underlying disk backing changes (different UUID, different SCSI target, or new VMDK), the stored changeId no longer matches the disk’s sector‑level history, causing QueryChangedDiskAreas to return incomplete or no changed areas. This mismatch can lead to an incremental backup that appears successful but omits blocks that actually changed since the last good backup.

Recommended steps for this case

1. After the restore, query CBT state for each disk:

   Get-VM -Name <VMName> | Get-HardDisk | Select-Object Name, @{N='ChangeId';E={$_.ExtensionData.Backing.ChangeId}}, @{N='CTKEnabled';E={$_.ExtensionData.Backing.ctkEnabled}}

2. Check the VM advanced setting ctkEnabled (global switch) if needed.
3. If any disk reports a non‑null ChangeId but the disk backing has been recreated or the .ctk file appears stale, treat CBT as potentially invalid.
4. Either:
   • Instruct the backup product to force a full backup for the VM before the next incremental run, or
   • Manually disable and re‑enable CBT for the affected disks (via VM advanced settings scsiX:Y.ctkEnabled) and then quiesce the VM so a new changeId is generated.
5. After the forced full backup, verify that the next incremental reports a sensible amount of changed data (compare to the full backup size) to confirm CBT is sane.

One missing diagnostic detail that could change the recommendation

If you can confirm the exact vSphere/ESXi version and the restore method used (full VM restore vs. disk re‑attach vs. storage‑snapshot restore), we can tell whether any version‑specific automatic CBT reset exists. Without that detail, the safest universal approach is to force a full backup or reset CBT as described above.