SureBackup and Instant VM Recoveries have started failing

[michaelryancook]

We recently updated all of our ESXi hosts to 5.5 Update 3a (from 5.5 Update 2) and our Veeam B&R servers to v8 Update 3 (from v8 Update 2). We also have been storage vmotioning VMs from our older Dell SAN to our new HP 3PAR SAN. Backups and replications are working without issue. However all of our SureBackup jobs started failing about 2 days after updating the servers. The error it fails on is that one of the vmdks on the first VM in the SureBackup job was not found. It happens on all jobs with different VMs but it appears to only fail if it is a VM we have storage vmotioned. The root of the issue seems to be the storage vmotioning. Looking at the datastore published by Veeam during the SureBackup job shows that the published drives' numbering does not match the source VM or the vmx file.

A similar issue is happening with instant vm recovery. It fails with the error "invalid snapshot" but looking at the datastore published by Veeam shows that the published drives' numbering does not match the source VM or the vmx file.

We do have a ticket open but it is not progressing very quickly. We were asked to add some registry settings for SureBackup power on retries but that did not help. Our case ID is 01094474.

Any assistance would be greatly appreciated.

[PTide]

Hi,

Could you please run any of the failing SureBackup or Instant Recovery jobs and go to your vPower NFS folder and check two things:

1. Open .vmx file and post what .vmdk paths are specified there
2. See if.vmdk files even appear in that folder

Thank you.

[michaelryancook]

Hi,

1. The vmx published during the job matches the source vmx. For example in the surebackup job I tried it had vmname_1.vmdk, vmname_2.vmdk and vmname_3.vmdk.

2. However the vmdks published there are misnumbered as vmname.vmdk, vmname_1.vmdk and vmname_2.vmdk.

Any ideas?

TIA

[PTide]

2. However the vmdks published there are misnumbered as vmname.vmdk, vmname_1.vmdk and vmname_2.vmdk.

For some reason the third .vmdk could not be mounted within the job time interval. How big is your third .vmdk? Please try to increase the timeout and number of retries and see if that helps.

Thank you.

[michaelryancook]

The third vmdk is not large. It has started happening with all the VMs that we have svmotioned so I don't think it is a size thing. The published vmdk numbering just does not match the source numbering or the published vmx. It starts one number lower. In my example above the third vmdk in the source is vmname_3.vmdk whereas it is being published as vmname_2.vmdk. It gets published and appears as the correct size but the wrong number.

My case has been escalated and I have to send in some extra logs today. Hopefully we will be able to find the issue/resolution.