Instant Vm Recovery Veeam

[Alysa Guillama]

WithInstant Recovery to Microsoft Hyper-V, you can immediately recover different workloads (VMs, EC2 instances, physical servers and so on) as Microsoft Hyper-V VMs. Instant Recovery to Microsoft Hyper-V can be helpful, for example, if you want to migrate your infrastructure from one environment to another, or you want to recover your infrastructure in a matter of minutes but with limited performance.

During recovery, Veeam Backup & Replication runs workloads directly from compressed and deduplicated backup files. This helps improve recovery time objectives (RTO), minimize disruption and downtime of production workloads. The workloads are recovered in a matter of minutes.

When you perform Instant Recovery, Veeam Backup & Replication creates dummy VMs and mounts to VMs workload disks directly from backups stored on backup repositories. These dummy VMs have limited I/O performance. To provide full I/O performance, you must migrate the VMs to the production site. For more information, see Migration of Recovered VMs to Production Site.

Besides disaster recovery matters, Instant Recovery can also be used for testing purposes. Instead of extracting workloads to production storage to perform regular disaster recovery (DR) testing, you can run a workload directly from a backup file, boot it and make sure the guest OS and applications are functioning properly. For more information, see Finalizing Instant Recovery to Microsoft Hyper-V.

Instant Recovery supports bulk processing so you can immediately recover multiple workloads at once. If you perform Instant Recovery for several workloads, Veeam Backup & Replication uses the resource scheduling mechanism to allocate and use optimal resources required for Instant Recovery. For details, see Resource Scheduling.

The driver on the target host knows which data has already been recovered permanently and does not redirect requests to such data, reading it directly from the disks of the recovered VM. Thus, performance of the instantly recovered VM will increase as more of the data is copied. When the VM is recovered completely, all Veeam Data Movers are stopped.

I did an instant recovery of 2 servers, these servers were from a different location and restored to a new location. Instant recovery went fine. When I migrate to production it creates a whole new server with the name -migrate. Never had this issue doin this to the same location.

I have not used IR in a while but if I am not mistaken there is something in the wizard to specify the suffix I believe. I could be wrong or maybe that is something new in 12.x if you are on that release. Checking on the documentation.

With Instant Recovery to VMware vSphere, you can immediately recover different workloads (VMs, EC2 instances, physical servers and so on) as VMware vSphere VMs to your production environment by running them...

To me, you spin the VM up directly in the veeam datastore. When it comes up (there), you are given the option to vmotion it from the veeam datastore to the vcenter (usually) datastore. So your backup datastore speed is the achillies heel of Instant Restore right? Ours is slow, but functional, so instant restores are kind of anemic, but when the stuff hits the fan, its better than nothing.

In this post, I will be discussing an issue we ran into when leveraging the instant recovery capability of Veeam Backup & Replication (VBR). The issue became apparent when we set up the preferred networks in VBR. The backup jobs and the standard restores both leveraged the preferred network as expected. We ran into an issue with instant recovery. While the mount phase leverages the preferred network this is not the case during the restore phase. That uses the default host management network. To make Veeam instant recovery use a preferred network we had to do some investigation and tweaking. This is what this blog post is all about.

We have a Hyper-V cluster, shared storage (FC), that acts as our source. We back up to a Scale Out Backup Repository that exists of several extend or standard repository. Next to the management network, all of the target and source nodes have connectivity to one or more 10/25Gbps networks. This is leveraged for CSV, live migrations, storage replication, etc. but also for the backup traffic via the Veeam Backup & Replication preferred network settings.

The IPs for the preferred networks are NOT registered in DNS. Note that the Veeam Backup & Replication server also has connectivity to the preferred networks. The reason for this is described in Optimize the Veeam preferred networks backup initialization speed.

To solve the issue we dive into the VBR logs, but also into the logs on both the repository/extent and the Hyper-V server where we restore the VM to. The logs confirmed what we already noticed. For backups and normal restores, it correctly decides to use the preferred network. With instant recovery for some reason, in the restore phase, it selects the default host network which is 1Gbps.

We first dive into the Agent.IR.DidierTest08.Mount.Backup-Side.log of our test VM instant recovery. Here we can see connections to our Hyper-V server node where instant recover the test VM over the preferred network. Note that is is the Hyper-V server node that acts as the client!

We first dive into the Agent.IR.DidierTest08.Mount.HyperV-Side.log of our test VM instant recovery.The mount log shows what we already know. It also shows that it is the Hyper-V server that initiates the connection. This does leverage the preferred network (10.10.110.0/24).

Based on our observations on the servers (networks used) and investigating the logs we conclude the following. During an instant recovery, the VM is mounted on the Hyper-V host (where the checkpoint is taken). During the mount phase, the Hyper-V host acts as the client, while the repository acts as the client. This leverages the preferred network. Now, during the restore phase, the repository acts as the client and connects to the Hyper-V host that acts as the server. This does not leverage the preferred network.

I have to thank the Veeam support engineer that worked on this with me. He investigated the logs that I sent him as well but with more insight than I have. Those were clean logs just showing reproductions of the issue in combination with a Camtasia Video of it all. That way I showed him what was happening and what I saw while he also had the matching logs to what he was looking at.

The WorkingHardInIT blog is a non commercial blog where technical information is shared with the global community. We only store the minimal data need for the shortest amount of time to be able to run the website and let you interact with it. We never share and/or sell any personal or general information about this website to anyone.

In a previous article, we overviewed one of the most significant enhancements of the new Veeam version 10 Backup & Replication software, Enhanced NAS Backup. Looking forward to doing a comprehensive review of the enhanced features of this new version, this time, we take a close look at the Instant VM Recovery feature. Veeam Instant VM Recovery, in version 10, now allows the system to recover from any Veeam backup to a VMware environment. Also new, is that Veeam now allows recovering multiple virtual machines at the same time. These two are critical and demanding techniques. Overall, Instant VM Recovery helps us to improve recovery time objectives (RTO), increase protection against ransomware attacks, and downtime of production workloads.

Through the updated Veeam documentation and material, we examined, for the Instant VM Recovery, what the keys are, in making the operations faster, and cost-effective. Veeam put the focus in three areas. The first one was the increasing RAM cache size to 1GB. Moreover, this RAM cache was optimized to measure all of the read blocks by flushing out the blocks that have been read least often, reducing latency, and enabling faster performance on recovery.

Another focused area is the intelligent prefetch of data blocks. By this, the Veeam engine looks ahead to what data blocks are going to be read next. Then, the system can intelligently read those blocks to make sure, even if the system is being recovered, they are ready. The intelligent prefetch of data blocks results in faster delivery. Veeam mentioned that depending on the system, performance could go a 5x increase in recovery speed. Besides these two enhancements, Veeam also optimized the interaction with the backup storage system. The engine takes advantage of synchronous I/O capability performing random reads and writes. For customers with high-performant storage systems, it means improving the performance of the recovery operation.

A very few changes have been made from the previous Veeam Backup & Replication console, in regards to the Instant VM Recovery feature. However, for a comprehensive overview, we require to add the steps to perform an instant VM recovery.

The operation can be carried out from one of two places. One method is from the ribbon menu under Restore and selecting the Instant VM Recovery option. A second method is browsing the backup that we have on disk and search for the failed VM that we want to recover.

We are sticking with the second option since it is the most practical. From the Backups menu, we select the workload that we want to restore, right-click it, and select the first option, Instant VM recovery.

3a8082e126