Replace virtual machine to backup without breaking deduplication

[clahi]

Veeam has been backing up a fairly large (6TB) virtual machine, until something bad happened*. Long story short, that virtual machine has now been deleted, and a new virtual machine using the same virtual hard disks is running. Veeam is obviously complaining it cannot find the original virtual machine.
Given the amount of data to store, I'd like to continue using the existing veeam backup job since it does wonders with deduplication (47TB of backups are only using 12TB on ReFS).

To avoid breaking the deduplication mechanism, can I just add the new virtual machine to the Veeam backup job and remove the old one, or do I need to trick veeam or hyper-v in some way to think that the old VM still exists?
In either case it will need to run a full backup since the change block tracking files are gone, but I'm hoping it doesn't have to use 6TB on the backup repository.

*something bad: hyper-v replication decided it couldn't merge anymore the automated checkpoints due to "An internal error occurred. (0x8007054F)" and, as part of the steps to remediate, the virtual machine object had to be deleted and a new one created pointing to the same virtual hard disks.

[Gostev]

I believe a trick will be needed involving configuration database edits to make Veeam think this new VMs which has a different unique ID is the old one. For sure you will need help from support to do this, and be sure to do a test restore later to make sure all is well (as who knows what else has changed between old and new VM).

[clahi]

thank you for confirming my suspicion.

Instead of editing the Veeam database, how about restoring only the VM descriptor files (.vmrs, .vmcx, .vmgs) from Veeam, importing that VM in the original hypervisor (using the restore option, which keeps the existing unique ID), reattaching the disks, and letting Veeam do its thing?

[Gostev]

I know for sure this does not work with VMware (you cannot preserve the original VM ID aka moRef). You can try and see if Hyper-V is different?

[clahi]

I tried it with a test virtual machine and indeed one or more IDs that Veeam cares about are different.
Contacted support (case 05064026). Thank you!

[clahi]

ended up figuring out the procedure by observing what the vcenter migration utility does. I'll leave it here in case it helps someone else. Needless to say, you should contact support first to get the official procedure. Use this at your own risk
Applies to veeam backup & replication 10

1. figure out what's the backup object id and the host instance id
SELECT [bObject_id], object_name FROM [BObjectsSensitiveInfo]
SELECT name, host_instance_id FROM [Hosts]
in the query below they are 'ACFCAF0F-DCCF-4421-A6AA-53C472A46E71' and 'HYPERV4' respectively

2. get the new VMID (objectid)
Get-Vm| where {$_.Name -eq 'writeTheVmNameHere'} | select Id
in the query below it's '66187473-52f8-48e7-8ac1-3675eed12ba4'

3. get the new BiosGuid (uuid)
get-vm "writeTheVmNameHere" | % { (gwmi -Namespace root\virtualization\v2 -Class msvm_computersystem -Filter ('ElementName="{0}"' -f $_.Name)).GetRelated('msvm_virtualsystemsettingdata') | select BIOSGUID }
in the query below it's 'e6112fa9-3909-4020-b402-4bb00f5c96d9'

4. replace the values in this sql query and run it

Code: Select all

USE [VeeamBackup];
GO
BEGIN TRANSACTION;

UPDATE [BObjects] SET [object_id] = '66187473-52f8-48e7-8ac1-3675eed12ba4', [uuid] = 'e6112fa9-3909-4020-b402-4bb00f5c96d9' WHERE [id] = 'ACFCAF0F-DCCF-4421-A6AA-53C472A46E71';

declare @usn int;
UPDATE [ReplicationInfo] set usn = usn + 1;
SELECT @usn = [ReplicationInfo].[usn] FROM [ReplicationInfo];

UPDATE [BObjects] SET [unique_key_hash] = HASHBYTES('MD5', '66187473-52f8-48e7-8ac1-3675eed12ba4' + 'HYPERV4'), [usn] = @usn WHERE ([id] = 'ACFCAF0F-DCCF-4421-A6AA-53C472A46E71');

commit TRANSACTION
END

[PetrM]

Hello,

Thanks for providing us with this information, however I'd like to emphasize that manual updates in Veeam configuration database are not supported and those queries can be performed only under the guidance of our support engineers.

Thanks!