Instant VM Recovery from Backup
Michael Bose, posted on June 21, 2017
Restoring a VM from backup may take significant time, as it is necessary to retrieve its data from a backup and reconstruct an original machine. However, in some cases, you do not have much time to wait until this process is complete. For example, the original VM got damaged, and you do not have a replica of it or the replica does not contain necessary data. The other case is a testing of software updates: you might want to see how they work before applying them to the production VM, and you want to do this quickly. So here, the Instant VM Recovery (Flash VM Boot) can help.
How Instant VM Recovery (Flash VM Boot) Works?
We will compare the usual restore from a backup to the Flash VM Boot, but first, let’s explain how it works. Flash VM Boot allows running VMs directly from the backups without reconstructing the entire machine first. Sounds like magic, but this is just a technology, so here are the steps of Flash VM Boot.
- NAKIVO Backup & Replication creates a VM on a target ESXi host
- Then it exposes the disk(s) of the VM to recover from a backup repository
- The product mounts the exposed disks to a newly created VM as iSCSI targets
- NAKIVO Backup & Replication boots the VM
Full Recovery vs Flash VM Boot
We took 2 VMs for the experiment: The first runs Windows Server 2016 and has two disks with 80 GB of data in total, the second one runs Ubuntu 16.04, has two disks and 540 GB of data in total. Then we did a backup of each machine: it resulted in 7.4 GB of data for the Windows VM, and 130.6 GB for the Ubuntu one (after deduplication and compression).
Full Recovery Results
We restored the VMs to the same ESXi host and applied the same job settings to make the experiment fair. Below are the results we received.
The smaller VM was recovered in almost seven minutes.
The larger VM recovery took an hour.
Flash Boot Recovery Results
Then we have to run the Flash VM Boot for each machine. By the way, launching Flash VM Boot is easy:
- In NAKIVO Backup & Replication, click on Recover.
- Select Flash VM Boot.
- On the first step of the wizard, select the backup and recovery point to proceed.
- Next, select the target host, datastore, and network to restore a VM. Note, that you can even specify different datastores for different VM disks (if you have more than one). It can be useful if you don’t have enough space on a specific storage.
- On the Schedule step, you can set a schedule for the job or choose to run it on demand.
- On the Options step, you can edit the job name, the name of recovered VM, choose whether to power it on or not; choose whether to assign a new MAC address to the recovered VM or not (this is useful if you recover the VM while the original one is still running. Otherwise the MAC addresses will conflict).
- Click Finish & Run and the Flash VM Boot process will start.
So, here are the Flash VM Boot recovery times:
The smaller VM:
The bigger VM:
We made the screenshots right after the VMs were recovered and launched in vSphere. As you can see, the whole recovery process took only twenty seconds for each VM, and both were fully-functional.
Here is the table with the results of the experiment:
|#||Guest OS||Disks||Amount of Backup Data||Time for Full Restore||Time for Flash VM Boot||Ratio (Full Recovery vs. Flash Boot)|
|Bigger VM||Ubuntu 16.04||2 disks, 540 GB thick provisioning||140.6 GB||1 h||20 s||177:1|
|Smaller VM||Windows Server 2016||2 disks, 80 GB thick provisioning||7.4 GB||7 m||20 s||11:1|
Obviously, the Flash VM Boot provides a near-instant VM recovery which is significantly faster than full recovery from a backup repository.
If you recovered a VM solely for test purposes, you could just discard it in NAKIVO Backup & Replication. This action will remove all the data and changes made to the recovered VM.
If you need to recover the VM permanently, you can use either move it using VMware vMotion or replicate it with NAKIVO Backup & Replication.
Flash VM Boot is a good choice for instant VM recovery, whether you need to test some updates or patches before applying them to the production VM or recover it after a disaster. However, if a disaster strikes your whole virtual environment, it does not suffice, that is why we would recommend having replicas of the most business-critical VMs on the separate host, so you still can be sure that your data is protected.