Instant VM Recovery (IVMR)
Usually reserved for the guests requiring the best possible RTOs, the Instant Recovery process is read intensive and its performance is directly related to the performance of the underlying repository.
With Veeam Backup & Replication v10 the Instant Recovery has been further enhanced: now it is possible to start multiple Instant Recovery sessions directly from the VBR console and it is possible to use this feature along with any Veeam backup, including Veeam Agents, Hyper-V VM’s, Nutanix AHV VM’s as well as cloud native backups from Veeam Backup for Azure and AWS.
Very good results can be obtained from standard drive repositories (sometimes even offering faster boot time than the production guest) while deduplication appliances might be considered carefully for such kind of use. Keep in mind that when working on its backup files to start the guest, Veeam Backup and Replication needs to access the metadata, which generates random small blocks read pattern on the repository.
Write redirections
Before it is started, the VM is snapshotted to redirect all written data to a separate disk file. Once booted, the guest will read existing blocks from the backup storage and write/re-read new blocks on the configured storage, whether being a datastore or a temporary file on the Veeam Mount Server local drive (Typically in C:\ProgramData\Veeam\Backup\IRCache\ but any disk may be used depending on the available free space).
To ensure consistent performance during the IVMR process, it is recommended to redirect writes on the same datastore where the instant-restored VMs will eventually be moved. This will not only improve the performance of the restored VM but it will also reduce the network traffic going through the Veeam Mount Server.
Redirecting the write cache on the target datastore will also reduce the amount of free space that needs to be available on the Mount Server as the .vswp (virtual machine swap file) will be created on the datastore. When planning a multiple Instant Recovery or powering on a VM configured with a high amount of RAM, this can make a huge difference since the swap file has the same size as the guest OS’ memory (minus the memory reservations if any).
When write cache is not used the amount of free disk space on the Veeam Mount Server must be equal to the total RAM size of the VM’s for which the Instant Recovery has been issued plus a 10% of their disks size to store all the changes.
Finalizing the process
The Instant Recovery process is a temporary state that requires to be finalized. The available options are:
- Use VMware Storage vMotion to migrate the restored VMs to the desired datastore without any downtime
- Use Veeam Quick Migration feature, if VMware Storage vMotion is not available
- Stop Sesssion : the restored VM will be unpublished without any change to the original restore point
Another option that might be considered would be to use a replication job to create an additional copy of the instant-recovered VM and plan a failover at a later time or during the next maintenance window, then stop the IVMR session. Of course, if for any reason that scenario was to be chosen, it would require more manual operations, proxy tasks and I/O.
Network ports
Below the network ports required to the Instant VM Recovery and the communication flow between all the involved components:
