Backup/Recovery Best Practices for Virtualized Environments
Virtualization’s great promise may be compromised if virtual machines can't be easily recovered.
by Ismail Azeri
The promise of virtualization to reduce computing costs is unquestionably attractive, which explains why Tom Bittman, Gartner Inc. vice president and distinguished analyst, predicted in October that more than half of all data centers will have virtualized some portion of their servers by the end of 2012. Virtualization’s silver lining can have a technological rain cloud attached to it, however, especially if you’re relying on the backup and recovery tools that came with your hypervisor.
Because it’s being adopted quickly, virtualization has the potential to create administrative frustrations that can compromise efficient backup and quick recovery. Most Windows and Linux server backup and recovery products aren’t equipped to protect both virtual and physical machines under a unified management scheme. As a result, IT administrators must invest in multiple protection schemes, each with proprietary backup/recovery functions and interfaces.
There are three protection problems that are seemingly inevitable in the move to virtualization. Fortunately there are also proven best practices to address them.
Frustration #1: Incompatible Backup Strategies
Most VM platforms offer the option of using their own backup/recovery software, but if you take that path, you’re effectively creating a separate and parallel backup and recovery regime for each virtual environment. Moreover, your virtual machine backups won’t be related to the data protection methods you’ve established for your physical servers.
Some third-party solutions have begun to address this problem by allowing you to manage both a specific virtual platform such as VMware® as well as your physical machines from a single management console. This approach works up to a point, but it doesn’t solve the problem for data centers hosting additional virtual machines from vendors such as Microsoft and Citrix. If you employ a separate backup and recovery solution for each additional virtual platform, you're bound to complicate recoveries and increase administrative headaches.
Best practice alternative: Use backup and recovery solutions that manage both physical and virtual machines from a single management console. If you have more than one type of VM, look for a solution that can recover the range of platforms you’re currently using. It’s safer to have a unified backup and recovery solution for all of your servers than to have multiple solutions. A single path to recovery can reduce the anxiety posed by a major threat to business continuity, and it should pay off in faster, more complete recoveries.
Frustration #2: High Administrative Requirements
The siren call of virtual machines says they’ll cost less to own than equivalent physical machines, and it’s true. However, it doesn’t necessarily mean they’ll be easier and less expensive to administer. Backup and recovery systems offered by virtual platform vendors and many third-party vendors lack the features, sophistication, and ease of use found in highly mature backup and recovery systems designed for physical machines. For instance, although a VM vendor may offer snapshot technology for backups, the backups probably won’t include file compression or data deduplication features for efficient storage of physical server backups. Without these features, disk storage requirements can climb just as quickly as your VM population.
Further, most backup software requires servers to be taken offline briefly to be imaged. This is a problem if you plan to run your VMs 24 hours a day for customer and partner-facing applications. Beyond that, many image snapshot technologies offer system-level recovery, but most don’t offer granular recovery despite the fact that accidental file deletions are vastly more common than virtual system failures.
Finally, most backup and recovery programs require a backup agent to be installed on each virtual machine. This adds administrative time, and time costs money.
Best practice alternative: Look for backup and recovery solutions that take advantage of rich feature sets that have been developed for physical machines. These can now be applied to the care and protection of your new virtual machines. For example, you should be able to optimize VM data for storage by taking advantage of decompression and deduplication offerings.
Further, your virtual recovery solution can include both system-level and granular (file-level) recoveries. “A lot of image snapshot technologies don’t offer granular recovery,” says Dante Orsini, Iland Internet Solutions’ vice president of business development in Houston. “Restoring volumes from a SAN isn’t easy. It’s better to have image-based recovery system that gives end users the option to recover just the files they need from a virtual machine backup in a minute or less rather than involving an administrator to recover a whole machine in a process that could take much longer.”
Third, look for a live-machine backup solution to avoid taking virtual machines offline for a backup. All these best practices -- long available for physical systems -- are just becoming available for VMs. They can relieve a substantial administrative workload.
Finally, we suggest investing in an agentless backup solution for your VMs. This can pay off in two ways. It can save time that would otherwise be required to administer the virtual machines, and it can save money because you’ll only need to buy only one license per physical host regardless of how many VMs it hosts.
Frustration #3: Costly Clouds
Creating an offsite virtual environment for disaster recovery can be expensive, negating some of the savings that drive data centers to virtualization. Consider a company that offers in-home health-care services across several states. It is considering a cloud-based recovery solution because it can’t afford to have its data center go down due to a natural or manufactured disaster. After contacting several cloud-based service companies, the company finds the ongoing cost is prohibitive because the standby virtual machines are always running.
Best practice alternatives: For their mission-critical servers, the health-care company could choose a third-party standby cloud environment in which the VMs are maintained on standby as offline devices until they’re needed. In this case, both its virtual machine files and entire hard drive images of physical servers are initially shipped over a secure VPN and restored on offsite VMs and SANs, and they are restored every five minutes via incremental data backups stored on the SANs. In the event of a disaster, the company can quickly launch the standby VMs at the cloud services facility from anywhere, giving users near-continuous access. Maintenance costs remain low because the virtual machines consume minimal resources until they are actually launched.
For VMs that aren’t mission critical but are important to the company’s infrastructure, the health-care company chooses a still lower-cost cloud-based subscription service that places images of complete VMs and individual files at a secure site, protected using AES-256 encryption and password protection. If disaster strikes, the system images and the file data can be restored to systems the company assembles at a alternate location.
As organizations embrace virtualization, it’s increasingly important to protect virtual machines with the same care that’s always been applied to physical servers. Be sure to take full advantage of automation tools in your backup infrastructure: the more virtual machines you can set and forget under a highly automated professional backup plan, the easier it will be to take advantage of all that virtualization offers without being overwhelmed by it.
Ismail “Izzy” Azeri is vice president for business and corporate development at Acronis Inc. Previously, he led VMware’s corporate business development team, responsible for acquisitions, investments, and strategic partnerships. Earlier he served in several roles within EMC Corporation's corporate development and finance groups. You can contact the author at firstname.lastname@example.org.