Author:  Jason Mattox

Image-Based Data Recovery for Physical Systems

As it turns out, all of the same recovery options that apply to virtual machines as I described earlier in this blog series also apply to physical systems. What’s new is that you also get the option to keep the physical system running as a virtual machine rather than restoring it as a physical device.

To break this down, you can use the protected image to restore the entire physical system at a specific Point In Time (PIT). You can restore the whole image. You can restore it on the original physical system, or on an entirely new physical system. You can also restore it on a virtual server as a Virtual Machine.

As for a protected Virtual Machine image, you can also reach into the physical system image and pull out any individual piece of data that you might need to restore like a single file.

On either the virtual server or the physical system, the restore process can use the same process of injecting a binary to perform the restore job at the time that you need it. This makes recovery very flexible, because you don’t need to know in advance where you want to perform recovery. With Backup 1.0 systems, you have to know in advance – because the recovery system needs an agent. Without the agent, you cannot perform recovery.

Backup 2.0 methods, in contrast, take care of managing the recovery system as part of the recovery process. You just decide where you want to recover, and the Backup 2.0 system does the work.

Just as on a virtual server (see my blog entry from Jan 28), there are about 60 configuration attributes that describe the underlying physical system configuration. When restoring an image onto a new physical system that is not configured with identical network connections, disk structure, and so forth, it is possible for the administrator to change these settings to enable the recovery. Due to its impact on the OS, the only attribute which can be problematic to change is the number of CPUs.

Another option for recovery of physical systems is to restore the image to a virtual server, and then replicate parts of the image back to the physical system for recovery. This is particularly effective for individual file restore and is the recommended method.

Author:  Jason Mattox

Backup 2.0 technologies use images to re-invent how data is collected, transmitted and recovered during the data protection process. Image-based backup is intuitive on virtual systems, where images are created for Virtual Machines by the system. However, image-based backup can also be beneficial on physical systems with appropriate handling to create the image.

In this blog entry, I describe several options for creating images on physical systems. Created images can be used as a better basis for data protection.

Options for Converting a Physical System to an Image

On a physical system, there is no naturally-occurring single file which encapsulates the OS, application and system data. Creating such a file can be a relatively simple process. There are a few different methods which are available from Vizioncore to do this: system replication and using a binary injection model.

Converting a Physical System to an Image with Replication

Replicating the complete set of data required for the image from a physical system to a virtual server over the LAN is simple and easy to manage in an environment. Once established, the replicated image is kept current by sending only the changes in system configuration and data as they occur. Because only changes in the system and data are replicated, this is a fast and efficient method for creating an image of the physical system.

The replication occurs over a LAN between a physical system and a virtual server. Once on the virtual server, the physical image is available for image backup. In the event that you don’t want to store the physical image on a virtual server replication can also occur between a physical system and a Windows share location on the network, from which is can also be protected.

Converting a Physical System to an Image with Binary Injection

Another option that can be used to create a physical system image uses the same type of binary injection process described for backup of a virtual system in my January 26 discussion. 

Using binary injection avoids the need to deploy any software on the physical system, such as a backup agent. Instead, the binary file is injected into the system at run-time, does its job to create the image file on the physical system, and then is completely removed from the system.

I have been asked if injecting a binary isn’t kind of the same thing as an agent. It’s definitely not. This is a real difference in design that reinvents the operational experience of backup for administrators. Eliminating the need for an agent eliminates a huge amount of cost and administrative burden. Think about it: no agent means no deployment, no maintenance, no license tracking, and no upgrade. Injecting the binary at run-time means that the binary always matches the current version of the system and its applications. Removing the binary after the job is complete means that there is no ongoing overhead of running an agent in the background on the system.

Backup of a Converted Physical System Image

You might be wondering, if there is any difference in the backup process for a physical system image placed on a virtual server and a regular Virtual Machine image. The answer is no. The backup process works identically. This includes all of the efficiency capabilities built into the collection process for Backup 2.0, including compression and de-duplication.

In fact, the physical system image can operate like a Virtual Machine. This conversion process enables backup, and it also enables rapid conversion from physical to virtual machine deployments. For this reason, we often work with our customers to identify physical systems in their environment which are better suited to conversion to virtual machines more quickly. These include systems which are more static – which don’t often change their configurations and which don’t write new data. Systems like DNS servers, web servers, and security servers are good examples.

Systems which are static do not require frequent backup. So, why pay for expensive Backup 1.0 agents for those systems? Static systems are a great place to begin with image-based backup on physical systems.

Look for my next post soon on the topic of restoring physical systems with Backup 2.0.

Author:  Jason Mattox

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.

Other Resources:

Backup 2.0 web site:  http://www.vizioncore.com/backup20/