Changed Block Tracking (CBT) is a VMware feature introduced in vSphere 4.0 in order to implement native incremental backup at source level. VMware VDAP uses this technology and so all backup and recovery software designed for VMware use it for speed the backup.
But last week a critical issue has been discovered on all vSphere 6 version (included the lates Update 1a) where Changed Block Tracking (CBT) data on ESXi 6 cannot be trusted.
This issue occurs due to an issue with CBT in the disklib area, this causes the change tracking information of I/Os that occur during snapshot consolidation to be lost. The main backup payload data is never lost and it is always written to the backend device. However, the corresponding change tracking information entries which occur during the consolidation task are missed. Subsequent calls to CBT APIs do not include these missed blocks, hence a backup based on this CBT data is inconsistent.
- Downgrade the affected ESXi hosts to version 5.5, and downgrade the virtual Hardware Version from 11 to 10, if necessary. For more information, see Reverting to a previous version of ESXi (1033604) and Downgrading the virtual machine hardware version in ESX/ESXi (1028019).
- Shutdown the virtual machine before doing an incremental backup.
- Do a full virtual machine backup rather than an incremental backup.
Veeam users have one more option, and that is to disable the use of CBT data in the advanced job settings. Your backups and replicas will remain incremental, but they will take longer, because the job will need to read the entire source disk to determine the changes. Disabling CBT is essential – otherwise, even Active Full backup may contain corruption, because CBT data is used there too to determine and skip zeroed regions of virtual disks. On the other hand, disabling CBT is sufficient to both prevent and remediate the issue, because this will make jobs physically compare latest state of disk in backup or replica with its actual state, and transfer any non-matching blocks over as a part of incremental backup (along with actually changed blocks), thus fixing any corruption that may already be in place.
So also after several months and one Update version, there still a reason to wait to move to vSphere 6.0 in production.
For more information on this issue see the KB2136854 (Backups with Changed Block Tracking can return incorrect changed sectors in ESXi 6.0).
Updated on November 25, 2015: patch ESXi600-201511401-BG should solve this issue. See also KB 2137546.