Summary: There is a known bug in ESXi 6.0 build 3825889 that makes incremental backups run as full backups instead. The initial fear was that the backups also could become corrupted, but VMwares KB article 2145895  states that the only known problem is that the backups will take longer and take up more space on the backup storage.

To fix the error, disable application-consistent backups (not recommended) or downgrade the ESXi hosts to the previous build (6.0 U2, build 3620759).

If you are running Virtual SAN (VSAN) downgrading ESXi is not recommended!

In either case, we recommend that you test your backups by regularly restoring them and verifying that they work as intended. Since many customers skip this testing since it’s too time consuming we recommend that you automate it or get a backup application that can automate it for you, such as Veeam Backup and Replication

How to determine whether you are affected by the bug:

  1. Your ESXi hosts are running version 6.0 EP6 (build 3825889)
  2. You are using a backup application that uses VMware’s vADP (vSphere APIs for Data Protection)
  3. Incremental backups are taking longer than usual and/or taking up more space than usual
  4. You are getting the following error message in the affected VMs’ vmware.log:
    SNAPSHOT:SnapshotBranchDisk: Failed to acquire current epoch for disk /vmfs/volumes/vmfs_uuid/vm_folder/vm_name.vmdk : Change tracking is not active for this disk 572


Picking up the error message in the vmware.log files is usually not easy, but using vRealize Log Insight (included with vCenter Server) and some hacking, you can get the VMs’ log files indexed, searchable and alertable.

You might also be able to spot the error in your backup application’s logs and alerts.

Stay tuned for updates on VMware’s actions and updates on this bug.