Move VMX from one datastore to another without full backup

[paulow1978]

Hi,

I need to unregister a few of our VM's from our VMWare 6.7 cluster and register them again once I have moved the VMX file. Is there a way to do this so that Veeam backup does not have to do a full backup again afterwards?

thanks,

Paul

[Egor Yakovlev]

Hi Paul,

with Unregistering|Registering a VM, VMware will reset VM's MoRefID as well as dependent CBT table, rendering incremental backup to read entire disk(VM will be treated as new).
There is nothing we can do to avoid Full backup, but to map subsequent backups to an existing backup chain.

Can't you move VMs via vMotion without unregistering?

/Thanks!

[paulow1978]

ah yes I remember the moref issue now. At one point I did get around this by editing the moref id in the veeam db (about three years ago). Something like this: https://myitblog.co.uk/veeam/change-vm- ... -database/

I can power down the vm's and do an offline vmotion as it were but I am fairly sure you cannot move the vmx file doing this. I may be wrong! I will have a look at it today.

It is such a pain doing this sort of stuff. We often end up having to move vm's and their data to new datastores on new SAN's etc which means doing a full backup again. This is kind of ok but some of our vm's have 5 or 6TB in which means it can take all weekend to backup one vm again so means I have to spend multiple weekends migrating over a handful of vm's to new datastores. In the current situation, I moved all of the data drives over which was fine but then realised I hadnt moved the vmx files which basically means a full backup again for moving a tiny file. It would be really cool if Veeam created a little add in for each server whereby it has a unique id in so that when things like unregiatering and registering a vm are done, you can click up anupdate button in the Veeam gui to update the moref for the vm. I can dream

anyway thanks for the reminder about moref's and vmotion. I should be able to get around it now.

[Egor Yakovlev]

Well, ID trick just solves "job doesn't see new VM automatically" but will not solve "CBT returns full vmdk size" problem. Job will continue to run, but with each backup we query VMware CBT for the VM in question, and VMware will return entire disk to us for new VM(aka re-registered one) first backup. So backup will be "incremental" type(.vib) but of a full VM backup in size.
If storages are under same vCenter server, you should be able to migrate VMs from one to another with no MoRefID change, nor CBT reset.

[Gostev]

backup will be "incremental" type(.vib) but of a full VM backup in size

If this was the case @Egor Yakovlev , then our vCenter Migration utility would not be so popular

No, of course the incremental backup will be of normal in size even if CBT returns the entire disk as changed, since we don't only rely on CBT to determine what blocks have changed. It would be a terrible idea indeed, because CBT also returns blocks as changed even if they were merely overwritten with the same content. If I remember our testing from the early days correctly, on average every other block returned by CBT does not actually have their content changed.

The behavior you're describing (incremental with a size of the full) happens only when no mo-Ref update was performed, because in this case Veeam observes a brand new VM and needs to capture its entire state as a part of an incremental job run.