Home / server / Questions / 507135
Accepted
SimonJGreen
Asked: 2013-05-13 13:23:18 +0800 CST

CBT Soap Fault from VMWare when runnnig Veeam backup

  • 772

We frequently see errors like this in our backup jobs:

10/05/2013 12:21:18 :: Cannot use CBT: Soap fault. Error caused by file /vmfs/volumes/781f6afc-ea228458/VDED-CIT-010(Exchange EX01)/VDED-CIT-010(Exchange EX01).vmdkDetail: '', endpoint: ''

In the last job that ran 11 out of 235 VMs backed up had this as a warning.

As a full example here's the output from statistics for one VM:

09/05/2013 22:02:14 :: Queued for processing at 09/05/2013 22:02:14
12/05/2013 02:30:00 :: Required backup infrastructure resources have been assigned
12/05/2013 02:30:02 :: VM processing started at 12/05/2013 02:30:02
12/05/2013 02:30:02 :: VM size: 20.0 GB (3.9 GB used)
12/05/2013 02:30:02 :: Using source proxy 10.24.0.11 [nbd]
12/05/2013 02:30:36 :: Creating VM snapshot
12/05/2013 02:30:46 :: Saving '[SAN3-NFS2] VDED-IL-001(LB)/VDED-IL-001(LB).vmx'
12/05/2013 02:30:51 :: Saving '[SAN3-NFS2] VDED-IL-001(LB)/VDED-IL-001(LB).vmxf'
12/05/2013 02:30:56 :: Saving '[SAN3-NFS2] VDED-IL-001(LB)/VDED-IL-001(LB).nvram'
12/05/2013 02:31:01 :: Hard Disk 1 (20.0 GB)
12/05/2013 02:31:14 :: Cannot use CBT: Soap fault. Error caused by file /vmfs/volumes/ca67d9a6-d95e1a1f/VDED-IL-001(LB)/VDED-IL-001(LB)-000001.vmdkDetail: '', endpoint: ''
12/05/2013 02:42:17 :: Removing VM snapshot
12/05/2013 02:42:21 :: Finalizing
12/05/2013 02:42:30 :: Network traffic verification detected no corrupted blocks
12/05/2013 02:42:30 :: Busy: Source 99% > Proxy 4% > Network 0% > Target 0%
12/05/2013 02:42:30 :: Primary bottleneck: Source
12/05/2013 02:42:30 :: Processing finished with warnings at 12/05/2013 02:42:30

My question is:

  1. What does this error mean exactly?
  2. If it's a problem (I think it makes VMs transfer the whole disk rather than changes, so it's not ideal) how can I fix it?
backup

2 Answers

  1. Best Answer

    The error means that Veeam cannot identify what blocks have changed. This could have numerous causes, for example, your storage was powered down without to shut down the VMs via guest OS first.

    The fix is fairly simple but it does require powercycling the VM, see KB:1113 - How to reset CBT. From the KB article:

    1. Power off the VM
    2. Right click the VM, click "Edit settings", find the "Options" tab and click "Configuration Parameters"
    3. Set the "ctkEnabled" value to false
    4. Set the "scsi0:x.ctkEnabled" value to false for each disk of the VM in question5. Open the source folder and remove any -CTK.VMDK files.
    5. Power on the VM
    6. Power off the VM again. This step is needed to update the CTK table.
    7. Power on the VM
    8. Rerun Backup or Replication job to re-enable CBT
    • 4

  2. I have the same issue after an unexpected power failure. I got the issue resolved by creating a snapshot of each vms and deleted. then run the Backup and worked

    • 0