Looking for something else?
Gone are the good old days of daily backups to tape, where the biggest issues were 24-hour backup windows, triage of failed backup jobs and feeding tapes into the voracious maw of ever-larger tape libraries. Prior to server virtualization, backup of physical environments was gradually changing from tape-only to disk-to-disk backup plus virtual tape libraries. Even with these media changes, the fundamentals of backup were the same, both in concept and basic operation. The advent of x86 server virtualization proved to be a disruptive technology, with a good deal of that disruption rippling through backup operations. Although traditional (i.e., physical) backup was always problematic, it was at least predictable. Virtualization changed all that, with servers moving dynamically, and being created or eliminated in minutes.
Server virtualization and its challenges are ubiquitous
By now, the vast majority of organizations have implemented virtual servers, with many achieving up to 90% virtualization rates. That means virtualization is being used for mission-critical applications, not just test/development platforms. Many of the applications running in virtualized environments use databases, including Oracle RAC, and may have near-zero recovery point objectives (RPOs) combined with recovery time objectives (RTOs) of minutes, not hours. Moreover, in physical deployments, a meager 10% to 30% CPU utilization rate is typical, but virtualization has driven the utilization rate north of 80%, leaving scant processing resources for backup jobs without impacting business processing. Traditional architectures are simply insufficient to meet these challenges, forcing IT managers to examine other offerings.
One thing that hasn't changed is putting proper emphasis on the "recovery" part of "backup and recovery." That's always been the case, but the dynamic nature of virtual servers makes recovery more challenging. Servers migrate unpredictably, even across data centers. Complicating matters is that an IT organization's headcount is increasing at a stingy rate, if at all. With smaller administrative support staffs, organizations need self-service portals and restore wizards to simplify recovery and give users the means to meet their own more stringent service demands.
If you're in an organization that still relies on traditional backup applications for your virtual infrastructure, you've probably encountered one or more of the following problems: network bottlenecks, missing backup elements, missed service-level agreements or even the cardinal sin of backup -- unrecoverable systems. Applications for virtual server-specific backups have reinvigorated the backup/recovery marketplace. Let's look at the process of evaluating products for virtual server backups.
Use this virtual server backups product checklist to help you evaluate the features your organization needs
Step 1: Inventory your needs
Everyone's familiar with the developer's adage "garbage in, garbage out." This applies to evaluating products, too. Taking the time to articulate and document your needs ensures that nothing major is skipped, and it's the first line of defense against a poor purchase decision. Here's a list of the major assessment categories:
- Current deficiencies. If you're looking for a new product, it means the one you're currently using is deficient. List the deficiencies. The chances are good they relate to events that occurred with a painful result. Was the root cause a lack of product features, difficult operations or something else? There's probably a theme to the failures that can guide you in evaluating new products.
- Application catalog. What's the nature of the applications supported? Are they mostly file-based solutions, databases or a near-equal mix? Do you use specialized databases, such as Teradata, that may require special consideration? The hardware estate may also provide a go/no go with regard to specific products and their support of those platforms.
- Physical versus virtual mix. Do you have legacy platforms that will never be virtualized and may require special backup considerations? To what degree do you need to skew a backup solution toward either the virtual or physical at the expense of the other? If you need to make a compromise, or are willing to, in what way are you willing to do so?
- Service-level requirements. Many organizations don't have formal RPOs and RTOs. Don't be like them. No product (or IT organization) can fulfill requirements if nobody knows what they are. It's critical to know if your potential solution must provide near-continuous protection or simpler periodic backup.
From an IT organization perspective, there are some additional fundamental questions to be answered. Nearly all organizations will be coming from a position of having a traditional incumbent vendor in place. Best-practice guidelines suggest that organizations should have no more than two backup/recovery software vendors; too many different products complicate management and operations. The incumbent vendor (or vendors) will almost automatically be on the virtual server backup shortlist, but maybe not. If an organization is fundamentally unhappy with its current vendor, moving to a virtual server offering may be a golden opportunity to make a change or consolidate vendors.
Step 2: Prioritize functionality
As a new product category emerges, it starts with highly differentiable products that offer both clear choices and difficult decisions. Over time, vendors enhance their products to the point where there's little functional differentiation. At that point, the key criteria changes from what a product does to how well it does it and how easy it is to use. The more features a product has, the more unwieldy it often becomes. Traditional backups have certainly reached that far end of the maturity spectrum, but virtual server backups are somewhere between the two extremes. Here are some features you'll find in the various products.
Must-haves: We'll assume a backup/recovery product has the base-level functionality to do what the name implies. In the virtual server world, here are a few additional feature items, without which you may be dealing with a showstopper:
- Multiple hypervisor support. If you have more than one hypervisor deployed, then this is a must-have feature; you don't want separate backup products for VMware and Hyper-V, for example. Nevertheless, different products may be better suited to one hypervisor or another. Match this to your environment.
- Crash consistency. What happens if a virtual machine (VM) fails or is migrated during backup operations? Will the product ensure data isn't lost, given all the scenarios introduced by VM movement?
- Simultaneous, multiple VM backup. Some traditional backup products back up VMs one at a time. Each job impacts the performance of all the other VMs and may even cause VM migration. Being able to back up all VMs on a physical server without performance impact is required.
- Platform support. The product has to support your infrastructure, whether it's virtual or physical, and if you're backing up to a backup appliance. This includes OS versions, hypervisor versions and firmware/driver versions. Version-specific limitations are the bane of IT organizations.
Nice-to-haves: The items listed below may be considered "must-haves" by some organizations, but strictly speaking they're not necessary for a functional solution. But they are nice to have.
- Deduplication is currently so pervasive in storage systems that it has become "table stakes" in the environment. For backup products, it's not a must-have because most arrays have their own deduplication and many organizations back up to an appliance with built-in deduplication. But this raises an important point: How will the backup software interact with deduplicated sources or targets? Is it more efficient to dedupe as part of the backup process or to allow the target device to handle it? And not all deduplication is equal. Arrays may offer only a 2:1 reduction, whereas with an appliance it may be 20:1 or more. How does the backup software compare and should it supersede the other systems? Deduplication works well on common file system data, but less so on audio/video files.
- Encryption, both in-flight and at rest, has become commonplace on storage devices. Encrypting backups is a best practice, especially if data is to be moved off-site in any form. As a general rule, encryption is best done at the target hardware level (i.e., the backup appliance or tape drive) to offload the processing from the CPU. It's important to learn how encryption at any level will impact deduplication. As a rule, encrypted data deduplicates poorly. Thus, deduplication and encryption may be best done on the target device, making it irrelevant to the backup software decision.
- Snapshot recovery. Some products support both their own snapshot functionality and manage array-based snapshots. Ultimately, snapshotting is the only way to get very low and near-zero RPOs. Managing array-based snapshots is essentially adding these snaps to the backup catalog. In addition, the snapshots facilitate backups that don't impact the application. Make sure the backup software supports your flavor of array software.
- Synthetic fulls. In the days of daily backups, physical full backups made synthetic fulls useful in only a handful of cases. With virtual server backups that offer near-continuous backup and around-the-clock operations, being able to create a synthetic full for point-in-time recovery or compliance is definitely a nice-to-have.
- Self-service portals and recovery wizards. For routine types of recoveries, such as single files or emails, self-service portals significantly increase end-user satisfaction and assist in meeting RTOs.
- Array integration. Some backup software leverages features of specific arrays. If this applies to your environment, it may give one product an edge over another.
- Tape support. Not all virtual server backup products support tape directly. If tape support is a requirement, it may be necessary to have two products, one for the virtual environment and one to manage the tape copies. This is less than optimal. While tape support may not strictly be a must-have, it's pretty darn close for those organizations that use tape in any capacity -- that is to say, most organizations.
- Agentless deployment. Using agents to deploy software isn't the end of the world, but most IT administrators hate having to manage them. Agentless deployment is therefore a plus in most cases. Specific functionality that demands use of an agent could override this preference.
Step 3: Trust but verify
President Reagan famously quipped that America should "trust but verify" in negotiations with the Soviets. And it's not a bad principle when it comes to backup/recovery vendors. Sometimes, in the rush to meet functional parity with competitors, vendors bring a feature to market that meets the definition in name only and leaves much to be desired. Consequently, a proof-of-concept now may save months of frustration later. As with any other product, nobody wants Version 1.0, even if it's just a specific feature. A feature that's been generally available for six months has usually had the most egregious bugs worked out. Even so, there's no such thing as a "standard" organization. Inexplicable anomalies may trip up the most well-tested application. If you've followed all the other steps in ensuring a thorough buying process, don't shortcut the proof-of-concept step. The pressure of an urgent system rebuild is a bad time to find out that marketing claims were just a bit exaggerated or that there was an unknown incompatibility. To paraphrase the old carpenter's adage, "Test twice, buy once."
About the author:
Phil Goodwin is a storage consultant and freelance writer.