Feature Request: Better ability to map VM backups after storage or vcenter move

[Lunatic Magnet]

We recently migrated to a VXRail Vsan from Dell Compellent SAN. VMs were migrated without issue. Unfortunately Veeam sees all of the VMs as new and wants to start the backup chain over. For those with forever forward incremental backups this effectively means doubling your storage footprint while retention runs its course on the original chain. For us (and likely many customers) we did not have double the storage for this.

We've also experienced times when Veeam sees the VM as "different" when seemingly nothing had changed (vcenter, hardware version etc) this also resulted in doubling the backup footprint for that job. We submitted support calls for this and the answer was effectively "oh well just start over".

The second example, while really inconvenient, was workable but the first example caused us a couple weeks of extra work. It would be nice to be able to change a backup (pointing to a GUID or something similar) so backup chains do not have to start over.

[foggy]

Veeam B&R tracks VMs by their moref ID, which changes upon VM re-registration in vCenter. How did you perform the migration? If you had used storage vMotion keeping VM IDs intact, you wouldn't have to start over.

[Lunatic Magnet]

Sorry I should have stated it's a different vcenter which, as you said, causes the moref ID to change. In the second example nothing had changed (vcenter, storage, hardware version) that we were aware of.

Found this thread vmware-vsphere-f24/manually-updating-mo ... 61851.html which mentions that if the datastore changed (us in first example) the CBT is different which would cause the chain to start over.
In this thread vmware-vsphere-f24/vm-moved-to-new-vcen ... 8-210.html it mentions the tool is provided as a convenience and not really supported because Vmware doesn't support changing the moref ID. Perhaps a mechanism that effectively says "moref ID 1234 is the same VM as 5678" could be useful in certain scenarios rather than just changing it outright.

[mweissen13]

I second this request. At the least there should be a supported, documented way to do this "MoRef change" manually. This especially useful for small customers which might not even have a vCenter, but 2-3 standalone ESX hosts.

[oliverL]

There exists a procedure generated by the Veeam Support to remap the moref-IDs after changing the vCenter.

Altough i don't know if it's already supported for vSphere 7+

Also CBT won't be reseted after a Storage vMotion. VMs with CBT enabled have "ctk" files for their respective VMDKs and those ctk files will be available after a Storage vMtoion.

[mweissen13]

> There exists a procedure generated by the Veeam Support to remap the moref-IDs after changing the vCenter.
That's correct. However, this procudure currently doesn't work when the VM is also backed up via Cloud Connect. In that case the official statement from support is: well, just start a fresh backup chain...

Also, I don't fully understand why this can't be a normal procedure (like assigning an imported backup chain to a job), without the need to always open a support case. All that's needed would be another window (Advanced assignment...) where an existing VM backup could be assigned to an existing VM.

[Vitaliy S.]

Also, I don't fully understand why this can't be a normal procedure (like assigning an imported backup chain to a job), without the need to always open a support case. All that's needed would be another window (Advanced assignment...) where an existing VM backup could be assigned to an existing VM.

There are certain scenarios where moref change can cause other unpredicted results, that's why the tool (and the proposed FR) provided by our support team has limitations.

[foggy]

Moreover, that would require direct interaction with the Veeam B&R database that we do not recommend doing without our engineers' assistance.