Instant VM recovery, also called recovery-in-place, allows a backup snapshot of a virtual machine (VM) to run temporarily on secondary storage after a failure or disaster occurs.
One of the big barriers to disaster recovery is the amount of time it takes to recover data, according to expert Brien Posey. Instant recovery seeks to eliminate that window by redirecting the user workload to the backup server.
Since instant VM recovery happens behind the scenes, users are generally unaware that it is going on. Once it's finished, the user workload is redirected back to the original VM.
But there are several misconceptions about instant recovery, Posey notes. For example, the instant recovery process is not truly instant. It takes a couple of minutes to put the new VM in place. Also, while it might have been true at one time that instant recovery only works for VMware, today it is also available on Hyper-V.
And while instant VM recovery doesn't require identical primary and secondary hardware to make the process work, it's important for administrators to test and make sure that backup hardware can support a production environment.
Transcript - Instant VM recovery best practices
Recovery-in-place / instant VM recovery
Editor's note: The following is a transcript of a video clip from Brien Posey's Tech Talk discussion with Sarah Wilson, site editor in Tech Target's Storage Media Group. This transcript has been edited for clarity.
Sarah Wilson: Hi, I'm Sarah Wilson, a site editor for the Storage Media Group. Joining me today to discuss data protection is Brien Posey. Hi, Brien. How are you?
Brien Posey: Doing well, thank you.
Sarah: Is performance a big issue with instant VM recovery?
Brien: There are really three things going on at the same time on the backup server. First, the backup server is still continuing to process the usual backup workload. Assuming that you're using continuous data protection, which most of the in-place solutions are, you've got an ongoing backup process that's running. Second, the backup server's having to host that virtual machine, possibly even multiple VMs, depending on the nature of the failure, and the user workload that is being used on those VMs. Third, you've also got the recovery effort going on in the background.
There can be a performance impact. But planning can keep that from happening. When you're planning the backup infrastructure, you have to assume that this sort of thing is going to happen from time to time. And make sure that the storage infrastructure being used on your backups is capable of dealing with that, and that your storage connectivity isn't going to be saturated by the increased workload.
Brien: You certainly could use replication -- that's always an option. But you have to understand that replication doesn't work all that well for every workload yet. I do think that day is coming very soon but it's not quite there yet. There are also additional costs for that, because you have to either invest in a secondary data center or invest in cloud services that you can use as a place to replicate your workloads. For smaller organizations, the replication approach might be outside of the budget. In-place recovery tends to work a lot better for smaller organizations, whereas larger organizations might prefer to use the failover approach.
Sarah: What about recovery-in-place in the cloud? Has that become the norm for a cloud-based disaster recovery?
Brien: It tends to be neglected. But I think that organizations should seek to minimize, if not eliminate, the data storage on mobile devices, so that way, backing up those devices is a non-issue. If data is being stored on those devices, it's a good idea to use an enterprise file sync-and-share solution. The data is automatically synced back to the organization where it can be better protected. And the data resides in an encrypted vault on the device, so that way, if the device is lost, stolen or otherwise compromised, that data remains encrypted and secure.
Sarah: Can file sync-and-share be a form of backup, and what are the benefits and drawbacks of using it that way?
Brien: File sync and share is and isn't a backup, all at the same time. It's a backup in the sense that data that gets created on the mobile device is copied back to a server on the back end. In that sense, you're creating a copy of the data and it could be thought of as a backup. But I don't tend to think of it as a true backup process because you're not actually creating a static copy of the data. The data is really just a replica of whatever's on the mobile device. If something happens and the user accidentally erases the data on the mobile device, that change is going to get replicated back to the server as well, and you lose your level of protection there.
Typically what you would do instead is run a more formalized backup process against the enterprise server that is receiving the replicated changes from the mobile device.
Sarah: Thank you for being here today, Brien. That wraps up this video about data protection with Brien Posey. I'm Sarah Wilson, site editor for the Storage Media Group. Thanks for watching.