Veeam Wires Crossed

[aobrien]

Hello,

I am hoping someone can shed some light on an issue I'm having. We are using Veeam B&R 11 Enterprise Plus Edition. We have 4 ESXi servers (not using VCenter) and we had to restore one of the servers using a backup OS that was cloned. Because of that, we had some VMs that needed to be registered again from the datastore. After registering those VMs, it seems Veeam got its morefIDs mixed up (again) and I had to manually go through each backup job and choose the correct VM to be backed up. In some cases, the VM was still the right one with a 0B size, so it had to be removed and added back. In other cases, the VM was not correct, so it had to be removed and the right VM had to be added. In this case, is there a way to avoid this? Is there a fix in a later version?

Any answers/theories would be greatly appreciated..

Thank you.

[edh]

Version of Vmware and VCenter?

[aobrien]

Vmware version is 7.0.1. We are not using VCenter, just standalone Vmware.

[Gostev]

When you first add a VM to a job, Veeam queries its morefID and memorizes it in the configuration database. This stored value cannot magically change so Veeam will keep using this same morefID forever for the given job. So, if you see any sort of "mix up" requiring to re-add the same VMs to a job again, then it can only mean something is changing morefIDs for your VMs on ESXi host to values which are different than they were before. You should understand what this something this, perhaps ESXi host logs will shed some light.

[tsightler]

As Gostev notes, it's important to be aware that it is ESXi that keeps moRef IDs. If you have 4 ESXi hosts, each host has an independent database for tracking MoRef IDs and such MoRef IDs can even be duplicated across ESXi hosts. That is, ESXi host 1 might have a VM with MoRef-ID vm-10, and ESXi host 2 can also have a VM with MoRef-ID of vm-10. Because of this, Veeam tracks MoRef IDs per-host, so the actual identifier user to uniquely identify a VM is the combination of the host ID+VM MoRef-ID.

Anything you do that changes the Host ID, will mean that Veeam will see everything on that host as a new object. Above you stated that your "restored the ESXi server from a backup OS". It's not really clear what this means, but if this involved re-adding the host it would look like a new ESXi host to Veeam and thus all the VMs would have to be readded to jobs.

When using vCenter, then it is up to vCenter to track these changes across hosts, although you can still end up with a case where, if an ESXi host is unexpectedly replaced without properly moving VMs to another host, you can end up with orphaned VMs in vCenter which will have to be re-registered.

[aobrien]

Thank you both for the feedback. I am admittedly a bit late in responding but I think this answers my question. We are booting VMware ESXi 7.0.1 from a USB in one of our ESXi hosts. We had made an image copy of this USB in case of failure and had to end up using the clone USB with ESXi on it. After that is when I noticed some of the backup jobs in Veeam were not correct. Some had the right VM (we always name the job the name of the VM) but had 0KB backup size, and some had different VMs. I noticed that the jobs that had the wrong VM had a pattern. If a job had a wrong VM, that VM's job also was not correct. Could this have to do with bringing up a cloned version of the OS?