How do I map to backups after moving VM into another vCenter

[VeeBR]

Hello,

Recenlty, I had to move one of my VMs into a new vCenter. This VM is a part of a Veeam backup job that contains other VMs. Both vCenters are in the Veeam Backup Infrastructure.

How do I map this moved VM to point to the default repository where its incremental and full backups already exits? Do I map the whole backup job or is there a way to map just the VM to its backup?

Thank you.

[HannesK]

Hello,
although it's not officially supported, you can do that by changing the MoRefID: vmware-vsphere-f24/manually-updating-mo ... 61851.html

Veeam is not using the VM name for safety reasons (imagine what happens if a customer would rename a VM). So that ID is what we refer to.

Best regards,
Hannes

[oleg.feoktistov]

Hi,

Other than directly modifying SQL entries, you might as well use Powershell methods to update target hostId and VM MoRefs directly for backup objects:

SCRIPT DELETED

You could parse host Ids and MoRefs from csv file and then pass them as arguments to the method in the loop above.
Just make sure that powershell picks the correct order of Ids from a file to avoid further confusion.

This approach is also unsupported, but looks more concise. I'd recommend to try it on a test environment first, anyways.

Cheers,
Oleg

[VeeBR]

Thank you all, this helps tremendously.

[hgreguric]

Hello,

Method with Powershell actually worked? If I understood correctly I fetch new Host and MorefIDs and just paste the arguments into the powershell and backupchain will continue?

[PetrM]

Hello,

Just wondering: any chance to create a new job for the migrated VM? I think it wouldn't be a big challenge if you had enough free space on the backup repository.

We cannot predict what kind of issues would happen in future due to "manual" update of configuration database entries. For example an object can be referenced from several tables, not only from BObjects or Hosts. A partial update (f.e. 2 tables out of X) might result in inconsistent state of Veeam database, please keep in mind that Veeam support won't be able to help you with troubleshooting if you encounter a problem related to this procedure.

If MoRefID change is the only available option for you: please don't forget to backup configuration database before doing any changes and it's better to try the method on a test environment at first as Oleg has suggested.

Thanks!

[soncscy]

I'm not in the middle of a migration right now, but can someone elaborate a bit on the details of the method? Am I reading too far into the method name?

UpdateObjectHostIdObjectIdAndSaveOldInfo

Is there some database backup that this does as well before committing the change up? Or this is a one-way method?

Basically, if I get it right:

I need to:

1. Get the objects in a backup job
2. Get the moref IDs of the VMs on the new vCenter/changed moref ids
3. Get the hostID as recorded in Veeam (I cannot seem to find a UUID from VMware that lines up with this cmdlet)
4. (extra) match the Veeam Host ID with a real host/vCenter from the VMware environment
5. Loop over all the objects in backup, match the VM to a VM found in step 2, record the moref id of the matched VM
6. Match the VM's host in VMware to the hostID found in Veeam
7. Update the job object using UpdateObjectHostIdObjectIdAndSaveOldInfo() and feed it the UUIDs from step 5 and 6

Do I have this workflow right?
If I make a goof, is there a rollback procedure as the method name implies or my only option is a configuration restore/db rollback?

[hgreguric]

I have tested but pasting commands or running as a script returns errors.

name of the job is moref
host id remained the same, and the moref ID of the VM changed to VirtualMachine-vm-3757.

backup = Get-VBRBackup -Name 'moref'
$objects = $backup.GetObjects()
foreach ($object in $objects) {
$object.UpdateObjectHostIdObjectIdAndSaveOldInfo(guid HostSystem-host-1925, VirtualMachine-vm-3757) }
# where HostId is target Host Id and objId is new MoRef for a migrated VM

Code: Select all

Error:
At C:\Users\Administrator\Desktop\script.ps1:4 char:54
+     $object.UpdateObjectHostIdObjectIdAndSaveOldInfo(guid HostSystem- ...
+                                                      ~
Missing ')' in method call.
At C:\Users\Administrator\Desktop\script.ps1:4 char:54
+     $object.UpdateObjectHostIdObjectIdAndSaveOldInfo(guid HostSystem- ...
+                                                      ~~~~
Unexpected token 'guid' in expression or statement.
At C:\Users\Administrator\Desktop\script.ps1:3 char:31
+ foreach ($object in $objects) {
+                               ~
Missing closing '}' in statement block or type definition.
At C:\Users\Administrator\Desktop\script.ps1:4 char:103
+ ... IdAndSaveOldInfo(guid HostSystem-host-1925, VirtualMachine-vm-3757) }
+                                                                       ~
Unexpected token ')' in expression or statement.
At C:\Users\Administrator\Desktop\script.ps1:4 char:105
+ ... IdAndSaveOldInfo(guid HostSystem-host-1925, VirtualMachine-vm-3757) }
+                                                                         ~
Unexpected token '}' in expression or statement.
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : MissingEndParenthesisInMethodCall

[oleg.feoktistov]

Hi all,

@soncscy, as they say: ".NET method name is never too long to read".

Actually, there is a backup of data. Specifically, a backup of old VM moRef. When you invoke the remapping method, 2 tables are being updated: [dbo].[BObjects] (new object data) and [dbo].[BObjectsMigrated] (old data for migrated VMs. Old moRefs are in old_object_id column). Just keep in mind that old_host_id column gets updated with the new host id. Old host id is actually never saved.

Your workflow is right. Since only old moRef is backed up, the way I see it is to note old host id somewhere else and rollback using the same method in case it goes wrong.

@hgreguric, I just wrote an example with data types required for the method. A fully working script example would look like that:

SCRIPT DELETED

This method should mirror the behaviour of this tool.
So much information for unsupported stuff, but I hope it helps.

Thanks,
Oleg

[oleg.feoktistov]

Had to delete original scripts from my posts due to the nature of the workaround being too risky. The amount and the tech details of the steps needed to do it correctly might already be confusing, but it can be exacerbated even further if we consider probable points of failure that can be introduced in this internal method with new updates and releases.

If you already have this script or can retrace it from this thread, please, beware of using it. It can lead to unpredictable outcome.

With good care and best regards,
Oleg