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

Changed Block Tracking (CBT) allows VADP-based backup software to run incremental backups by reading only the regions of a virtual disk that changed since the previous pass. The goal is to determine whether CBT data remains trustworthy immediately after a VM is restored from a VADP backup, so the next incremental job does not silently produce an incomplete chain.

The uncertainty is whether vSphere invalidates the tracking data (.ctk files) automatically when a restore replaces a VM's disks, or whether that state can survive the restore and no longer match the restored disk contents. Restore paths differ — full VM restore, re-attaching restored disks, and restores built on storage snapshots — and it is unclear whether CBT handling is consistent across all of them.

• Does vSphere reset CBT automatically when a VM is restored from a VADP backup, or must the tracking be reset manually before the next incremental run?
• If CBT persists across the restore, is the first incremental backup guaranteed to be consistent, or should a full backup be forced first?
• Is there a documented, supported way to confirm the CBT state of restored disks, and does the behavior vary between vSphere releases?