PowerShell • Re: Get-VBRJobObject : Incorrect/inaccurate Object (EVmware) Location

Hello,

Thanks for your reply.

Re -1 :

When you move 15 VMs, for sample, being dispatched over different VBR Backup jobs,
you may easily forget one in the VBR Job update process.
This results of old VM still being backuped while new one not.

Let's take a sample... Migrating VM1,2 & 3 from OldVC to NewVC ...
VM4 and 5 NOT being migrated yet.
The reason ? If VMs 1-5 are Acc/Dev/Tst and Prod Vms of a given app,
I could migrate Dev/Test in a first step, then Acc and finally Prod inb different
time slot.

VBR Job 1 : VM1(OldVC), VM2(OldVC), VM3(OldVC), VM4(OldVC), VM5(OldVC)

Let's replicate Initial full sync, I have VM1(OldVC), VM2(OldVC), VM3(OldVC) running
and VM1(NewVC), VM2(NewVC), VM3(NewVC) powered off.
At migration time, I shutdown VM1(OldVC), VM2(OldVC), VM3(OldVC), replicate (Incr-sync) and
start migrted VM1(NewVC), VM2(NewVC), VM3(NewVC).

After migration, VM1(OldVC), VM2(OldVC), VM3(OldVC) still exists and are powered off.
VM1(NewVC), VM2(NewVC), VM3(NewVC) are powered on, running.

If I no not modify the VBRJob 1, then VM1(OldVC), VM2(OldVC), VM3(OldVC) will still be backup,
while VM1(NewVC), VM2(NewVC), VM3(NewVC) not.

I then update the VBR Job 1 as VM1(NewVC), VM2(NewVC), VM3(OldVC), VM4(OldVC), VM5(OldVC)
Take care, VM3(OldVC) is incorrect. Still exist in old VC but VM3(NewVC) is not backuped.

The VBR Backup job will be successfull till VM3(OldVC) is deleted from disk.
At that time, an error will pop-up because VM3(OldVC) does not exist anymore and will
realize that VM3(NewVC) is unprotected, with a potential data lose.

So, if I keep VM1(OldVC), VM2(OldVC), VM3(OldVC) for 1 week after migration,
my VM3(NewVC) is unprotected for 1 week. Reason of my cross-check script.

The script I pasted is just an extract. It takes as input a list of VMs being migrated
and it should compare, with collected location output, if location of these VMs to NOT match
old VCenter anymore and match New Vcenter. It will also care if VMs have be deleted
from job and not be added again.

From VBR Job Edit, when selecting Virtual machine and handling long VM list, it is easy
to miss one or select wrong one. Reason why I migrate by set of VMs using temp RP.

My goal is so to run a powershell script that check from veeam configuration
that all of my migrated VMs to be correctly set-up in backup job(s) just after migration.
A kind of cross-check, Errare humanum est.


Re -2 :
Yes, if you move the replica VM to new resource pool and then update the VBR job,
the location from VBR Job Object does match. But if you move the VM from RP,
then VBR Job Object is inaccurate.

I do not directly understand the role of the location field from VBR Job Object
if the value is not reliable...

Futhermore, from this VBR Job Object object, there are NO way to join the object with
an object that can be retrieved from neither Find-ViVBREntity, Find-VBRxxxxxxxxx

Using object name is not reliable as Veeam accepting mutiple VCenter/HyperV/Cloud ...
You may have 2 DataCenters, using 2 different VCenters, having a given VM with identical
VM Name in each VCenter, both VCenter being known into Veeam.
Find-VBRViEntity will gather both VM Object.
In this case, how can you track with VM from which VCenter is backuped ?

The Location field would be the key solution ...

In my case, VMs have coded names :
LXPTEST1 : LX for Linux, P for Prod. should be in RP PROD_LINUX
VWTTEST2 : VW for VM Windows, T for Test. Should be in RP TEST_WINDOWS
VWPTEST3 : VW for VM Windows, P for Prod. Should be in RP PROD_WINDOWS

Location is also to cross-check the VMs to be stored in correct RP
I agree, for this point, I could use Power-CLI script to do the check but
why reinventing wheel when possible not to do it

Thanks for your attention and care,

Warm regards,

Th

Statistics: Posted by ThierryF — Jun 20, 2025 6:56 am

---