Data Protection 6 silently decides not to backup very large VM's disks

[zoran4afc]

I created 6TB storage for Data Protection 6 and tried to backup VM having two disk 128 GB and one 2TB.

The backup job finishes quickly without any error or warning.

Loged in FLR, I can see that only smaller disks are backed up.

Despite of the Data Recovery notorious reputation, I liked it better, because it is very simple to configure a backup window at a weekly basis, without lenght limitations, for each job separately.

At VDP, you can configure max. 16 hour backup window, only daily based, common for all backup jobs.

But, VMDR can't have total backup storage larger that 2TB, and it likes to corrupt the backups from time to time (hence "notorious reputation").

[brunofernandez1]

im not an expert in Data Protection from vmware.

But i remember that there is a limit on Data Protection. For bigger infrastrucutres you have to use Data Protection Advance.

i think the limit is 2TB:

VMware KB: License usage for vSphere Data Protection Advanced 5.5 for Replication

[zoran4afc]

Actually, you can have data store up to 8TB in VDP6.

VDP Advanced is retired as of March the 1st, 2015, and it's feautes are now part of VDP6.

There is no reference of VDP in vSphere6 Configuration Maximums.

Anyway, my VM's disk are 1.75TB and 1.95TB.

[Raudi]

Is it possible that the source of your problem is the same as here:

https://communities.vmware.com/message/2488602#2488602

In arcserve will be reported that the used blocks can't be identified, when i shutdown vm's or put the vm to a host with no other vm then the backup works.

I have a memory probem...

Perhaps you can check the vmkwarning.log if there are memory errors from cbt.

[zoran4afc]

Hi Raudy,

I found (similar for the other silently failed backup job):

<182>Mar 22 03:00:22 esx1.hdinfo.local vmkernel: cpu7:17480948)CBT: 1540: Disconnecting the cbt device 1647cbe8-cbt with filehandle 373804008

<182>Mar 22 03:00:22 esx1.hdinfo.local vmkernel: cpu6:17480948)CBT: 1540: Disconnecting the cbt device 13dccbeb-cbt with filehandle 333237227

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)CBT: 2214: Created device 1700cbf0-cbt for cbt driver with filehandle 385928176

<180>Mar 22 03:00:23 esx1.hdinfo.local vmkwarning: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 60

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 60

<180>Mar 22 03:00:23 esx1.hdinfo.local vmkwarning: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 59

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 59

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)CBT: 1540: Disconnecting the cbt device 1700cbf0-cbt with filehandle 385928176

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)CBT: 2214: Created device 15e3cbef-cbt for cbt driver with filehandle 367250415

<180>Mar 22 03:00:23 esx1.hdinfo.local vmkwarning: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 60

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 60

<180>Mar 22 03:00:23 esx1.hdinfo.local vmkwarning: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 59

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 59

<180>Mar 22 03:00:23 esx1.hdinfo.local vmkwarning: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 43

<182>Mar 22 03:00:23 esx1.hdinfo.local vmkernel: cpu4:17480948)WARNING: CBT: 2039: Unsupported ioctl 43

So, no memory shortage here, but CBT warnings are present.

According to KB2058568: "Resolution:  These warning messages are harmless and can be safely ignored."

Also: Re: Errror - CBT: 986: Unsupported ioctl 58

The VDP reports backup succeded, although one LUN is not backed up at all. Was that case with your issue too?

[Raudi]

No i use a different backup application "arcserve udp", and this application tells me that he can't backup the vm. But on a other VM the quiesced snapshot Fails. I have different errors that all have the same source.

Was only an idea, that this is perhaps the same reason... So seems to be different.