Share this post

Virtualization is a fact of life in information technology today. More and more systems are migrating to virtual machines (VMs) or to entire private cloud platforms, while major vendors have moved to fully support their platforms on virtual systems. Although this shift has led to an increase in efficiency and reliability, it also raises some unique issues in terms of recovery of data (as opposed to the recovery of entire servers).

When the subject is data recovery (DR), it is important for organizations to look at two key factors most affected by the switch to virtualization solutions. They are:

1. Most organizations are hybrid shops with both physical and virtual systems, many of which are likely supplied by multiple vendors.

2. Recovery might mean restoration of data to a system that is either configured or might have to be configured differently than the original.

Hybrid Considerations

Hybrid infrastructure creates DR issues by requiring multiple solutions to protect and recover information. Virtual protection typically utilizes VM-based snapshot techniques and cannot be applied to the physical machines within an environment. Phys­ical servers rely mostly on application and platform specific agent-based protection solutions, which may not work the same way on VMs.

There are many available solutions that can get around this particular issue. Hybrid environments can, for example, use the agents for physical servers within the guest operating systems of VMs. As long as the overhead on each VM is minimal, the cumulative impact on the VM host can often be less than that caused by the snapshot operations across all VMs.

Alternately, storage-based solutions can allow for universal DR platforms, protecting the SAN-attached disks that contain both physical server data volumes and the VM virtual disks. For physical servers, the one drawback to using the storage-based systems is that the system drive might not be on volumes backed up by the company’s storage-based DR structure.

Recovery of data objects becomes problematic, however, when utilizing whole-disk or VM snapshot tools. Since the data would have to be restored to either another running system or into a new VM, restoration of single objects might be outside the scope of the tool-set. This is a preferred option when recovering the entire system, but what if you are attempting to avoid this procedure?

Restoration of Data

That leads us to the second scenario. When the goal is to only restore data to another system, restoration of the entire VM (or entire volume of a physical server) is an unwanted and time-consuming step. DR tools need to restore individual data objects (a file, directory, database, etc.) in order to provide the most flexibility, which should be considered a requirement for a variety of DR scenarios.

The least common scenario, although it is one that clearly exemplifies this concept, is a recovery/upgrade combination event. A server is lost to a disaster, and the decision is made to perform an OS or application upgrade during restoration of the VM to functioning status. Since a rebuild might be required to restore service, upgrading during the process may take care of both problems at once. Normally, restoration of service immediately is the overriding goal of DR, but if an upgrade is already planned and mapped out, using the failure event as the trigger for the upgrade is a sensible approach.

In this instance, data alone must be retrieved from the protection solutions that were used to protect the entire system. Then it must then be restored to a new system with a different server identity and possibly a different OS platform entirely. If the only recovery available is the entire virtual volume, entire VM or another option where individual data objects cannot be restored on their own, then all information must be recovered to a temporary platform to extract the information necessary to complete the migration.

While the recovery/upgrade combination is an extreme circumstance, DR to another system for the sake of speed is far more common. When a database VM fails, the organization may choose to attach databases of the failed device to another database server. In this way, services can be restored much faster than rebuilding or restoring the entire failed server or VM. The combined system will run at a performance deficit until a new VM is provisioned, but at least it will be running and available.

Once again, as was the case for the recovery/upgrade scenario, the basic issues are the same. If the only restore ability is by volume or by VM as a whole, the system must be restored to temporary hardware, which defeats the purpose of restoring into an existing VM to save time. The above scenarios come into play when an entire VM or physical machine is lost or when, because of the disaster event, its data is completely unavailable.

Far more DR emergencies, however, are caused by the accidental or malicious destruction of data objects within a given server environment. Such events can be as simple as the accidental deletion of a file or as complex as a virus attack corrupting targeted tables within a much larger system of databases. In these instances, the focus shifts away from restoring the data to “rewinding” the data to a point in time before the deletion/corruption/attack occurred. This, of course, needs to be targeted as quickly as possible so end-users of non-effected data are not disrupted during restoration of the missing information. Here again, the majority of VM backup tools focus on protection of the virtual disk as a whole either in real-time or on long-reaching schedules (every 12 hours, once per day, etc.) This, unfortunately, limits restoration to only the latest “version” of the data, requiring manual fixes to correct for data corruption; or reliance on a largely outdated version of the data from a previous point in time.

New Generation of Tools

New generations of tools are being brought to market every day, with many specifically created to deal with this type of solution set. Both VM manufacturers and third-party providers are introducing new tools sets that can protect both physical and virtual servers. Many are also producing tools for recovery of data objects or an entire VM from the same backup of the environment.

Virtualization has its share of data recovery issues to overcome. Some of them, e.g. restoration of data to different machines, have been around since the physical data center became mainstream. Others, such as the need to back up multiple virtual machines as a unit, are unique to the virtual world. Simplifying all of these goals takes careful planning and the selection of the correct combination of native and third-party tools. It’s the best way to ensure that data will be restored when and where it’s wanted and needed.