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:
7.6 and newer (CBTv2)
1. Taking a first backup
When a VM is backed up for the first time Altaro will go through the entire VM as there will be no CBT data available.
2. 48 Hours elapsed since the previous backup
CBT v2 for Windows Server 2012 and 2012 R2 is based on persistent ShadowCopies upon which a BITMAP file is created containing the changes between ShadowCopies. These BITMAP files are only kept for 48Hrs. If a VM is not backed up within the timeframe then the next backup will skip CBT and scan for changes during the backup operation. CBT will continue from that operations onwards unless another 48Hrs are elapsed between backups.
3. ShadowCopies are manually removed from the host volumes
In the event that a ShadowCopy created on a host or CSV is cleared manually by the administrator or a thirds party application, CBT will be skipped for the next backup. Once the new ShadowCopy is taken upon the next backup operation, CBT will then be available for subsequent backups.
7.5 and older
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.