BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
There are a number of misconceptions about instant recovery, but there are five I encounter on a somewhat regular basis:
1. There is no performance hit
When instant recovery is used, the recovered virtual machine (VM) runs from backup storage. Typically, this is storage that is deduplicated and being actively used for other backup processes. Furthermore, there is a recovery process happening in the background, which also consumes storage I/O.
2. There is zero downtime
I've encountered posts on Internet message boards from people who think instant recovery is the same as high availability. Unlike a failover clustering solution, instant recovery does involve a degree of downtime. Instant recoveries are only performed after a failure has occurred and require manual intervention. In other words, the instant recovery process is not truly instant. It takes a couple of minutes to put the new VM in place.
3. It ruins your backups
The idea behind this myth is that if you allow a VM to run from the backup copy, the backup is modified by the running VM. However, the backup copy of the VM remains read-only. All write operations are directed to isolated storage known as a differencing disk. When operations are failed back to the primary VM, any changes can be merged.
4. There is no way to perform a point-in-time recovery
Another misconception is that instant recovery does not allow for point-in-time recovery. However, most backup products that support instant recovery will allow you to base an instant recovery on any available recovery point.
5. It only works for VMware
This might have been true at one time, but today instant recovery is also available on Hyper-V.
Why instant recovery makes more sense than traditional backup
Instant recovery performance issues