Backup and disaster recovery: Physical vs. virtual
Even though significant differences exist between backup and DR preparedness, many traditional DR systems still rely on backups to collect the data from client servers. The backup process involves a complex set of jobs, involving copying files and application data to a storage repository, which is then replicated to the off-site location. In this way, backups effectively divorce "user data" from the application and system data that's required to restore servers in a DR event. This means the restore, or recovery, part of a DR system that's using backups to collect data needs to reintegrate the backed-up data, through the often complex (and time-consuming) process of rebuilding servers, reloading applications and recopying the user data itself. A bare-metal recovery application can simplify these recovery steps but usually requires a different type of backup and adds the complexity -- and, often, additional cost -- of another process.
Compared with this DR process used by physical servers, virtual servers employ a much simpler process. A virtual server, or virtual machine (VM), encapsulates all the user data and all system data into a single image file, which is read from and written to directly by the applications running on that VM. Backup consists of simply copying these large server image files to the data protection system and updating them incrementally as they change over time. Disaster recovery for virtual servers involves moving these image files to the remote DR site, a much easier process than with traditional backup for DR. But the big difference is really on the recovery side.
Traditional recovery of physical servers typically starts by bringing data back from the DR site to the primary site (if it's still operable) or to a secondary site. It also involves getting enough physical servers to run the applications built and loaded, restoring data to them and restarting the applications. A faster alternative is to run these applications on standby servers from the DR location. Of course, this means buying assets that may never be used, but the cost of downtime may justify the investment.
For virtual servers, image files can be used to bring up a new server instance at any time. For a DR recovery, this means all that's needed is a copy of the server image and a virtual host to restart the VM. In one step the server and all applications can be restored. Server virtualization offers another advantage in that the server images stored off-site can be brought up on a relatively few virtual hosts at the DR location, drastically reducing the cost of idle assets.
Another advantage to virtual servers in DR is testing. Since DR, like backup, is essentially an insurance policy, testing to make sure it's in force is essential. For many companies struggling with the realities of just getting data off-site on a regular basis, testing may be a pipe dream. But with the consolidation of a company's servers into a few virtual hosts, remote testing of these VMs is relatively simple.
Leveraging virtual from the physical realm
While virtual servers deliver clear DR advantages over a physical server environment, physical servers can still realize some of the benefits of virtualization for disaster recovery, through the use of physical-to-virtual (P2V) conversion software.
P2V conversion software creates a server image file without actually running the server as a VM and can convert it back to a physical server for a traditional restore -- or the server image can be brought up as a virtual machine. Some P2V solutions can also maintain a virtual image of a physical server over time as changes are made to the physical server and its data. This enables physical servers to stay up to date and maintain their ability to be restored as a VM although they may never actually be run as virtual machines (unless a disaster happens).
Besides P2V software, there are also hardware systems available that include conversion software; together, they act as a backup appliance, converting physical servers' data to virtual server images and storing them locally. These image files can then be replicated to like hardware off-site, in a company facility or colocation site, or to the cloud. The same recovery options would be available: either restoring the server images to local hardware and restarting the servers or restarting them in a cloud service provider's data center on virtual host servers reserved for that purpose.
The cloud is a natural environment for leveraging the power of server virtualization for disaster recovery. Hybrid cloud storage systems can provide on-site primary storage and integrated cloud connectivity to seamlessly move VM images off-site. Cloud service providers can reserve virtual server host capacity needed to support the servers that a company's DR plans specify and even assist with periodic DR testing of those VMs. Combining the simplicity of virtual server images and the benefits of cloud storage can create a first-class DR system with flexibility and very attractive price points.
For VARs, server virtualization is an everyday topic of conversation with clients and prospects. Focusing on virtualization's disaster recovery capabilities can provide another strong use case to drive more interest and more project activity. Given the abundance of cloud technology vendors and cloud solutions available to storage VARs, getting your arms around DR with the virtual server environment should be time well spent.
About the author
Eric Slack, a senior analyst for Storage Switzerland, has more than 20 years of experience in high-technology industries holding technical management and marketing/sales positions in the computer storage, instrumentation, digital imaging and test equipment fields. He's spent the past 15 years in the data storage field, with storage hardware manufacturers and as a national storage integrator, designing and implementing open systems storage solutions for companies in the Western United States. Find Storage Switzerland's disclosure statement here.
This was first published in November 2010