Image-Based Backup: How Images are Restored on Virtual Systems

This is the second blog entry in a three-part series that answers the question: what is image-based data protection? In this series, I describe the detail of how images are collected and recovered. I describe this first for virtual machines, and then in the final entry I describe how the same approaches can work on physical systems.

Image-Based Data Recovery on Virtual Systems

Once we have preserved the image for a system at a specific Point In Time (PIT), as I described in the blog entry on Image-Based Data Collection, we can restore the whole image or any part of the image including individual files and application objects. In a later Backup 2.0 blog entry series, I will describe each recovery scenario in detail.

For now, though, I want to provide you with some detail on how we handle the virtual machine information and give you better image flexibility on recovery than most others in the market.

There are about 60 configuration attributes just on a vanilla virtual machine that we capture along with any changes going forward with the virtual machine virtual hardware when we make the image backup. This includes he number of Virtual Machine CPUs, the amount of memory, the number of NICs, the disk configuration, and so forth. This configuration data is the virtual hardware which makes your VM power on and present the correct virtual hardware to to the operating system on boot.

When we restore a VM using the image, we give let you edit the virtual hardware on restore. Where this can be particularly useful, is for the disk and network configuration settings because you’ll rarely have the exact same configurations supported between two physical ESX systems at your DR site, or if production environment is short on disk space.

Let’s look at the scenario in which we’ve got the original VM configured connected to two virtual disks and using two virtual NICs. The two virtual disks correspond at the physical ESX level to two instances of the virtual machine File System (VMFS), let’s say VMFS1 and VMFS2. The two virtual NICS correspond to two virtual switches and to two physical NICs on the system.

When we restore the image to a second ESX system as a new VM, that ESX system is more than likely to have a different configuration. Let’s say that we’ve got a physical ESX system with a single VMFS and a single switch. In this case, data from the two virtual disks will be restored into the single VMFS. Also, the two virtual NICS would run through the single switch on the system.

Now consider the case in which you must restore the VM image back to the original ESX server. Without access to the virtual hardware or the ability to redirect the virtual disk restore location , you would have to go through a multi-step process of restore. In that case all of the data for the two vdisks will be loaded into a single VMFS on the ESX system at the physical layer. Then, you would have to manually migrate the data for one virtual disk from the first VMFS to the second VMFS on the system, in order to recover the original configuration back into production.

With access to the virtual hardware and ability to redirect the virtual disk restore location on restore, we allow you to avoid a multi-step restore procedure. You can simply modify the virtual hardware during the restore process.