Instant Recovery for a BIG VM

[GabesVirtualWorld]

We're tasked with migrating a VM from Hyper-V to VMware with as little downtime as possible. Max 1hr. Since it is a 32TB VM, we can't do backup and restore because that would take way too long. Replication is still not possible between Hyper-V and VMware, leaves us with Instant recovery as the way to go. I’ve done a few migrations this way, but they were all 100GB VMs, so I never had to look at the details, it just worked. But for this big VM I have a few questions on the details:

- The manual says: "When you perform Instant Recovery, Veeam Backup & Replication mounts workload images to a host directly from backups stored on backup repositories. This means that Veeam Backup & Replication creates fully functioning “temporary spares” with limited I/O performance. To provide full I/O performance, you must migrate these "temporary spares" to the production site".

Question: The backup is on a physical hardened Linux repository with disks from a full flash array (Pure-X). When doing an instant recovery, will the NFS be created on the physical Linux server or on the proxy of the cluster in which we restore? What transfer limits will I hit, read speed of the Pure-X, network throughputof the physical linux server and then the VMotion nics of the ESXi host?

Question: We're expecting more than a day restore / vmotion time, will nightly backups interfere with the process since they will use the network cards of the linux backup respository or is Veeam protecting the host bandwith?

During the Instant recovery & Storage VMotion, the original VM will be offline, users will connect to the new VM running instant recovery. Reading this in the docs: "By default, all changes to virtual disks that take place while a recovered VM is running are logged to auxiliary redo log files residing on the NFS server (backup server or backup repository). These changes are discarded as soon as the recovered VM is removed, or merged if you migrate the VM to the production site."

Question:
So I need to make sure the backup repo has enough free space to hold the delta. When I monitor the backup delta of the past week, that would give me a good idea on how much space I need to supply I guess?

Question:
As the SVMotion will take quite some time, is there any way to do backups of this VM, is there a fallback scenario? When only the SVMotion fails and the VEEAM Instant recovery job stays open, I have the snapshot. But suppose the VM is migrated and doesn’t perform or whatever and we have to revert back to Hyper-V. Is there any way to rescue my changes?

What else should I pay attention to moving such a big VM?

[bct44]

Hello,

Question 1: Please check requirements for your mount server, this server need to be close as possible of the repo and have a good network path to the target hypervisor.
https://helpcenter.veeam.com/docs/backu ... =120#mount
Do you have any idea of the storage consumption of the VM (IOPS, latency...)?

Question 2: From my knowledge, there is no network loadbalancing on a linux repo.

Question 3: daily change rate of your vm could be a good indicator. If you want you can write redologs to another DS.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
During SVmotion please don't forget to make an exclusion if you have any backup jobs which could start a backup of this VM.

@Mildur Do you know if an entire vm restore/quick rollback to another location/target could be supported or works? if it is, it could be a great alternative scenario.

[GabesVirtualWorld]

When using storage VMotion, is the management nic of the ESXi host used or the VMotion nics? I remember from the old days, there was a limit on the management nic, not sure if that is still the case.

My colleague suggested that Veeam QuickMigration might be an option. In that way we can use Hot-Add on a proxy and fully use the bandwidth of the proxy.