Note: This article only applies up until V7.5 of Altaro VM Backup. From V7.6 on wards we've made improvements and released CBT v2 for Windows Server 2012 and 2012 R2.
Since the release of CBT in Altaro VMBackup 6.4.0 changes are being tracked in real time. This means that the scanning for changes phase of the backup can be bypassed as the changes are already picked up when the virtual machines are running.
In certain cases, CBT is skipped and the virtual machines will be scanned for changes. The below list outlines situations where CBT tracking data is skipped:
1. Taking a first backup
When a VM is backed up for the first time, including the first backup after Altaro VM Backup 6.4 or later is installed or updated to, CBT tracking is activated, however, data is not available for the first backup, as it still needs to be collected. It will be available for the second backup, and for any subsequent backup after that, unless one of the situations listed below is encountered.
2. Hyper-V host is rebooted or Altaro Services are restarted
When the Altaro SubAgent service is restarted, any existing CBT tracking data is deleted. CBT tracking is activated on the first backup taken after the service is restarted, but CBT will be available from the second backup onwards. This also applies if the Hyper-V server is rebooted.
3. Change in system date/time
If the date/time of the host machine where CBT tracking is activated changes by more than 2 minutes, CBT is skipped.
4. VM is off
CBT tracking can be activated on a VM which is off. However, CBT tracking data will not be available until 24 hours have elapsed between the time of the initial (first) backup, and the time of the last successful backup.
5. VM has been recently powered on
Even though CBT tracking might be activated on a VM which is powered off, CBT tracking data will not start until the first backup is taken. This has to be done after a minimum of 75 minutes that the VM is in running state.
If a backup is taken immediately after a VM starts, that changeset will not be valid. If another backup is taken 2 hours after the VM started, then that changeset is valid, and can be used to perform CBT on the upcoming third backup.
6. CSV Redirected access
CBT is skipped if redirected access is detected on a drive located on a CSV. This means that CBT is not supported on hosts running Windows Server 2008 R2.
To check the reason for your CSV being in redirected access mode, check the Cluster Events tab in Microsoft Windows Failover Cluster Manager, as shown below:
Ensure that you have the Failover Clustering feature installed on all nodes too. If not, you'll see this error listed.
7. Last successful backup is older than 8 days
If the last successful backup is older than 8 days, the CBT tracking data collected since the last backup is not used and CBT is skipped.
8. VM is migrated
This is closely related to point number 5 above ('VM has been recently powered on'). When a VM is migrated, the process hosting it is restarted, so CBT is not performed on the migrated VM until the VM's uptime is greater than 75 minutes.
9. VM is on but changeset is empty
If the VM is ON but no CBT data has been collected on the drive being validated (i.e. the changeset remains empty) then CBT is skipped.
10. VM is a Replica
Only live VMs support CBT tracking data. If a VM being backed up is a replica target (although not recommended) CBT will be skipped for this VM.