Not so long ago I was suffering from a Veeam Backup & Replication error:
| Processing server1 Error: The specified item was already backed up or backup was not completed. Failed to download disk. Reconnectable protocol device was closed. Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}. |
I wasn’t able to google a lot about it and everything seemed fine from connection point of view, so I was a little bit clueless about what’s going on. Most accurate google results were about settings of TCP offload on NICs, which seemed ok from the description of the error, but I was sure there is nothing set that could mess with the backup in this way.
Also there was a problem with just some (very few) servers I was migrating from Proxmox VE to the consolidated VMware vSphere environment. From that servers the very few were servers that were not migrated in one phase (all disks at once), but at least in two.
For the migration I used VMware vCenter Converter, which is a great tool, but the fact that you would be doing a migration of the same server/VM twice isn’t a good option for Veeam afterwards.
What can actually happen – you choose server1 to migrate, server1 has 4 volumes, which can be migrated, you choose to migrate all volumes in one go, but then you mess up something and choose to migrate some volume again or you migrate again some of the already migrated volumes to the ESXi on the same datastore.
The problem for Veeam is that you have a file structure like this:
..\server1\server1.vmdk
..\server1\server1-flat.vmdk
..\server1\server1_1.vmdk
..\server1\server1_1-flat.vmdk
..
...\server1\server1_3.vmdk
..\server1\server1_3-flat.vmdk
The problem that will be created by migrating multiple times is that the Converter will create a new folder the second time for the same physical server / VM and starts labeling disks from the beginning. You would end up with smt like this (in summary added to the above) if you would follow my example:
..\server1_1\server1.vmdk
..\server1_1\server1-flat.vmdk
Now you have 4 unique volumes inside your VM. ESXi doesn’t care if you have two disks labelled as server1.vmdk and to that you have corresponding server1-flat.vmdk in two separate folders – your VM will be working just fine. But oh boy… try to back it up with Veeam and you can be sure that sooner or later you will end up with the error message written above. By sooner or later I mean that on 800GB vmdk it failed on the first 3-5GB of data read, it was quite random but always in the beginning of the backup.
The solution is easy when you know that your problem is the same as mine – “just” perform storage migration elsewhere (to a different datastore) and then back to the designated datastore. This will make a cleanup of all file names – it will put all your vmdks in one folder and label them properly.
Then you should have no problem like this with Veeam backing up your VMs again.