v8: disks with identical names (case insensitive) error

[ITP-Stan]

We have two VM's that no longer back-up since upgrading to v8.

Error: The specified item was already backed up or backup was not completed. Failed to download disk. End of file Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.

These VM's have 2 disks but on different datastores.The name of the disks is the same, so both disks are named VMNAME.vmdk but one with capitals, other without capitals. The disks are on different datastores.

In v7 there was no problem with the back-up of these VM's and their disks. Support have confirmed this is a bug in v8. The soonest they can fix it is with Patch 1, due for at least another month.

A possible workaround is using storage vmotion on 1 of the disks, and the assumption this will change the name of the disk. However I tried this, and the name did not change (vsphere 5.1). Another option is manually (with powercli) changing the disk name, but for this the VM needs to be powerd down which is not always easy to do on production VM's that run 7 days a week.

[ITP-Stan]

I received private fix 39703 from support and can confirm this fixes the problem.

[Rockford]

Is there a link to the Private Fix we are having the same issue!

[foggy]

Please contact technical support directly to get the hotfix. Thanks.

[Rockford]

cheers and done.

[chjones]

Thanks for this post, Stan.

We had one VM giving the exact same error after an upgrade to v8. I checked it and it had two VMDKs with the same name, one in uppercase and the other in lowercase. Thankfully I am running vSphere 5.5 and a Storage vMotion did rename the files to both lowercase in the format of vmname_1.vmdk and vmname_2.vmdk.

I've re-run a backup of that VM which was failing constantly and it completed successfully.

Thanks for your post, I've had a support case open about it but didn't seem to be making much progress. This has saved me. Thank you!

[ITP-Stan]

Is this private fix included in patch1 for v8?
And can I apply Patch1 safely when I've used this private fix?

[foggy]

Stan, the recently released rollup is not the Patch #1, but just an update rollup that includes hot fixes for two specific issues around Hyper-V backup and replication in an easy to deploy bundle. Veeam B&R v8 Patch #1 that should include the fix for the above issue is scheduled to be released in about 2 weeks.

[Vitaliy S.]

And can I apply Patch1 safely when I've used this private fix?

Yes, you will be able to do this as well.

[ITP-Stan]

Thank you for the quick response.

[ChrisL]

Hi,

Any news on when v8 Patch 1 is to be released? Have just run into the same issue as this (similar VMDK names over different LUNs causing a naming conflict) and wondering whether to contact support for a private fix or just hang on. If the release is imminent (next few days) then I guess I'm probably better off hanging on.

Ta

Chris

[ChrisL]

...and yes, I'm aware that I'm posting this on Christmas Eve evening! but hey, there's no such thing as 'downtime' when it comes to backups, right?

[foggy]

Right, the patch is going through the pilot deployments right now, so it makes sense to hang on for a couple of days.

[ChrisL]

Brill, thanks Foggy!

[ChrisL]

Just to feed back, it looks like Patch 1 for v8 has indeed resolved this issue. Initial full (that I was trying to run at the time) and subsequent jobs have all run fine so far.

[changeupcharley]

Hello,

I am still seeing this error with the following configuration (across multiple customers):

[*]Console is located in site A
[*]Proxy (VMware AND Hyper-V on-host agent) are at site B
[*]Proxy is targeting either a \\cifs\share at site B ("local backup"), OR writing back to site A repository (SMB3 in the case I'm seeing)

Error:

[\\redacted.redacted.com\veeam\offsite.local.redacted_clone1\offsite.local.redacted_clone12014-11-13T170101.vbk]. Failed to download disk. End of file Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.


I'm running version 8 patch 1.

[foggy]

Charley, please contact technical support directly with any technical issues.

[AndyGDIT]

Hi All

Sorry to bring up an old topic, but i just updated to V8 U2a from U1 and I am seeing this issue. I have a case open (00937886). I saw that in this thread the U1 fixed the issue. Could something have been reverted in U2a?

Andy

[Gostev]

Ho, Andrew. Nothing has been reverted, this time it's a newly introduced bug deep in VDDK 6.0, so unfortunately we cannot fix it from our side easily. We have opened a support case with VMware, and meanwhile are planning to provide a fix that will detect such a VM configuration, and automatically failover processing from HOT ADD to NBD. Alternatively, you can apply any of the workarounds mentioned in KB2042. Thanks!

[AndyGDIT]

Thanks Gostev! Support gave me the same KB article and I have moved to Network Mode and it is working

[ChuckS42]

Ho, Andrew. Nothing has been reverted, this time it's a newly introduced bug deep in VDDK 6.0, so unfortunately we cannot fix it from our side easily. We have opened a support case with VMware, and meanwhile are planning to provide a fix that will detect such a VM configuration, and automatically failover processing from HOT ADD to NBD. Alternatively, you can apply any of the workarounds mentioned in KB2042. Thanks!

This one's a bit painful - NBD is a lot slower on fulls for large disks than Hot Add. Any word from VMware on a fix for the VDDK?

[PaulNSW]

Will this ever be fixed on VMware's side - or is this just how they do things now? (feature not a bug)

I'm currently running VDDK 5.5 (copied to VDDK 6 folder) to workaround this problem. I really don't want to have to rename all my disks, or move their SCSI nodes.

[ChuckS42]

Will this ever be fixed on VMware's side - or is this just how they do things now? (feature not a bug)

I'm currently running VDDK 5.5 (copied to VDDK 6 folder) to workaround this problem. I really don't want to have to rename all my disks, or move their SCSI nodes.

Interesting workaround (copying VDDK 5.5 files to VDDK 6 folder, I assume under C:\Program Files (x86)\Veeam\Backup Transport\x64\ from the VBR server to the Proxies). Any other side effects from doing this?

[PaulNSW]

Yep, that's exactly what I did; it was a suggestion from Veeam support when I opened a case about it. (though not mentioned in the KB article)

I've experienced no side effects for the last month or so, that I've been using it, and backups/replicas have been tested with Sure backup.

I'm running ESXi 5.5

[ChuckS42]

Yep, that's exactly what I did; it was a suggestion from Veeam support when I opened a case about it. (though not mentioned in the KB article)

I've experienced no side effects for the last month or so, that I've been using it, and backups/replicas have been tested with Sure backup.

I'm running ESXi 5.5

Hmm, didn't seem to make any difference. Seems the bug-avoidance code in Update 2b is forcing NDB mode regardless of which VDDK version is being used.

So, I ask again - is there a timeframe from VMware on a fix?

[PaulNSW]

Sorry, should have said that I was still on Update 2a while I did this. Unfortunately I updated to 2b and now the VDDK 5.5 workaround no longer helps, as you mentioned.

I tried changing the SCSI node numbers on the disks on one of my VMs, and when it rebooted, all disks were offline; Exchange was not happy about that!! I had to enable them again manually. My next replication failed with "Processing configuration Error: Cannot complete the operation because the file or folder [replica-store2] exch_replica/exch_2.vmdk already exists" - so I had to delete all my replicas and reseed again

However my normal backup worked without issue!


I wonder how hard it is to roll back to 2a...

[Bunce]

Given Veeam doesn't even think it important enough to identify differences in the release notes, wouldn't hold your breath..
http://forums.veeam.com/veeam-backup-re ... 29227.html

Release procedures 101: You make a release public - you make the release notes public. Doesn't matter whether it was out for a day or a year.

Were staying on V7, still too many issues.

[Gostev]

So, I ask again - is there a timeframe from VMware on a fix?

They are hoping to fix some of [many] issues VDDK 6.0 has introduced in vSphere 6 U1, but don't commit to fixing any specific issue.