Restore a single VMDK using Veeam Instant VM Recovery

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

Instant VM Recovery is one of the coolest feature of Veeam Backup & Replication. Regardless of the size of a VM, it allows to have it back in production and running in few minutes, because it’s not actually copied back into the production datastore, but directly executed from a backup file. It’s main use is to restore completely broken or lost VMs, but what if you want to restore a single VMDK, maybe because the original VM is fine and you only need one of its virtual disks? usually, a disk restore would require a complete binary restore into the production datastore, and if the disk is quite large it can take some time. What if you would be able to use Instant VM Recovery also for a single VMDK, instead of having to remove the old VM and swap it with the new one?

What usually happens

Since Instant VM Recovery restores the exact copy of the original VM, if this VM is still in place and running you need to guarantee the two VMs will not conflict. During the Instant Recovery wizard, you will can set a different VM name and a different datastore. It would be required to change also the portgroup in order to avoid IP conflicts, but for the scenario I’m describing, you will not need to power up the restored VM, so this task is useless.

Instant VM Recovery

Once the VM is published, you can edit the settings of the original VM and add an existing disk. You need to browse the Veeam NFS share, find the original disk, and add it as a secondary disk:

Add secondary existing disk

Once you try to save the new configuration however, an error appears:

VMDK UUID duplicate

Since having a duplicated UUID is not a good thing, you probably select No, and try another method.

What you can do

Simply, go and change the UUID before attaching the new disk. Open a command line, directly into the ESXi server or via SSH. With the command vmkfstools -J, you read the UUID of both original and restored disks:

~ # vmkfstools -J getuuid /vmfs/volumes/fas2020_vol2_dedup/dc02/dc02.vmdk
UUID is 60 00 C2 9b 70 ce c6 f3-11 fb fa 57 7d 36 dd 66
~ # vmkfstools -J getuuid /vmfs/volumes/VeeamBackup_VEEAMSRV/dc02_restored_50118104-cdeb-43eb-8c4d-f0c796aae9b8/dc02.vmdk
UUID is 60 00 C2 9b 70 ce c6 f3-11 fb fa 57 7d 36 dd 66

As you can see, they are effectively the same. Now, with another command you set a new UUID in the restored disk. Instead of getuuid, you use now setuuid:

~ # vmkfstools -J setuuid /vmfs/volumes/VeeamBackup_VEEAMSRV/dc02_restored_50118104-cdeb-43eb-8c4d-f0c796aae9b8/dc02.vmdk
UUID is 60 00 C2 91 0f 31 6d ef-c2 bb 65 d1 03 5e d1 ce

The disk has now a new UUID, and you can connect it to the original VM. Finally, inside the Guest OS, you can bring the disk online:

Connect restored VMDK

Finally, you can browse its content (the small 100 MB partition is the System Reserved, that you do not see usually when the disk is the boot disk):

Browse the content of the secondary disk

There is no problem at all in editing the UUID of the secondary disk: Veeam is always using the original backup file in read-only mode, as soon as you stop the publishing of the restored VM (after removing the disk from the original VM obviously!) all changes are lost. If instead you want to keep both disk, you can finalize the process with a simple storage vmotion of the whole VM.