Altaro VM Backup Support Centre



Changed Block Tracking Skip Conditions

Last Updated: Dec 01, 2016 04:11PM CET
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.
Facebook LinkedIn Twitter Google+ Blog

© 2016 Altaro Software
Customer service software powered by Desk.com
beta@altaro.com
http://assets1.desk.com/
false
desk
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
false
Invalid characters found
/customer/en/portal/articles/autocomplete