vSphere Data Protection restores a thin-provisioned disk as a thick-provisioned disk
search cancel

vSphere Data Protection restores a thin-provisioned disk as a thick-provisioned disk


Article ID: 326940


Updated On:


VMware vSphere ESXi


This article provides information on why restores are done as thick-provisioned or thin-provisioned disks, and how the capture of "in-use blocks" determines which type of provisioning will be applied upon restore.

  • After you take a CBT backup of a virtual machine with a thin-provisioned disk and restore to a new virtual machine, the restore is successful but the disk is restored as a thick-provisioned disk instead of thin-provisioned.
  • During the initial backup of the virtual machine, in the log file for the backup job (located at /usr/local/avamarclient/var-proxy-#), you see entries similar to:

    2013-03-08 10:50:15 avvcbimage Warning <16004>: Soap fault detected, Get In-Use Block problem, Msg:'SOAP 1.1 fault: "":ServerFaultCode [no subcode]
    "Error caused by file /vmfs/volumes/6c0378da-9f01ff6c/VMName/VMName.vmdk"
    2013-03-08 10:50:15 avvcbimage Warning <14654>: The in-use blocks (pass 1) could not be found for 'VDP-1362764949194c70ab320125690879340701d95f89b9fa46f1', using disk extents.
    2013-03-08 10:50:15 avvcbimage Info <14660>: In-use block offsets for disk 2000:
    Offset:0, Length:42949672960
    In-use Block offsets complete, count=1, totals: in-use=42949672960, unused=0
    2013-03-08 10:50:15 avvcbimage Info <16058>: changed-block or in-use lists are unavailable, performing full level zero backup


VMware vSphere Data Protection 5.1.x


This issue occurs when the in-use blocks are not returned during the initial backup of the virtual machine, which results in a thick restore.

The initial level 0 backup is the only time that in-use blocks are taken from the vCenter Server. It is not necessary afterward because the changed blocks are always a subset and are used.

The in-use blocks are critical on the initial backup. They are what place "holes" in the backup, which will not be restored. Essentially, if these holes are present in the backup, they will be skipped over during the restore process. If in-use blocks are not captured in the initial backup, then the holes are not present and the entire backup will be restored, which results in a thick restore.

Once cause of this issue is that the original backup is done on a powered-off virtual machine that has never been powered on. The software does not capture in-use blocks until the first power on.

There are other potential causes of this issue. If you see the log entries shown in the Symptoms section of this article, any restore done of that VMDK will end up as thick-provisioned.


To resolve this issue and avoid thin-provisioned backups restoring as thick-provisioned, ensure that the virtual machine is successfully powered on before the initial backup occurs.

Note: There are other possible situations which can cause the in-use blocks not to be found for a VMDK during its initial backup. One example is that a VMDK which is stored on NFS can fail to report in-use blocks and change blocks due to the restrictions VMware has placed on CBT queries in their API calls.

For more information, see Limitations on Changed Block Training section in the Virtual Disk API Programming Guide.