Instant Recovery and Migration from Veeam Data Vault

[gtelnet]

I've been doing some Instant Recovery/Migration tests from Veeam Data Vault with Cloud IBR and would like to put in a feature request to allow specifying Thin Disk via the REST API call /api/v1/restore/instantRecovery/vSphere/vm/{mountId}/migrate, as you allow in the UI.

When doing the migration of the Instant Recovery of an agent based backup or a HyperV backup to ESXi, it can take several hours for Veeam to "Prepare VM" which is how long it takes VMware to create the Thick eagerly zeroed disk for 10TB+ servers. My testing was done on NVME NFS storage with dual 25Gbps connectivity, so not slow hardware.

To confirm that Thick eager zeroed is the culprit, I ran an IR of an agent based backup of a server with a 450GB physical disk and only 32GB of data.

The thin provision IR migration took a total of 5 minutes and 29 seconds. First 5 minutes was spent "Processing Restore Hard Disks" which is when it was creating the thin vmdk and then 2 minutes was spent restoring the actual data (32GB worth of data).

The IR migration with the default of thick eager zeroed selected for the same server took a total of 20 minutes and 17 seconds (almost 400% longer). First 19 minutes was for the "Processing Hard Disks" task, compared to 5.5 minutes when selecting Thin, and the remaining couple minutes was restoring the actual data.

This enhancement to the REST API call would shave hours off of the recovery/migration time from Veeam Data Vault by having VMware quickly create the thin disks as well as eliminate wasted space on the recovery datastore for automated recoveries. Thank you!

[gtelnet]

Sorry, should have posted this to the REST API forum.

[oleg.feoktistov]

Hi Greg,

My apologies, must have completely missed your post. Thanks for the feature request. We have released some enhancements for instant recovery (Azure and Hyper-V support as targets) recently and will be adding more in the next product releases.
Disk type selection and mapping during IR migration to vSphere in particular is currently in our short-term plans.

Best regards,
Oleg

[gtelnet]

That's great to hear! We just ran an automated recovery yesterday for a client and the 'Provisioning Eager Zeroed Thick Disk' step took 18 hours and then the data restore only took 6 hours. Would love to eliminate the 18 hour portion by using the thin disk option for REST API initiated IR migrations and get their RTO down to 6 hours!

And another note - we had many issues with IR'd servers failing to boot when doing too many at a time with v12 and so far, we haven't been able to reproduce the issue with v13, so that's a huge improvement!