More and more companies are virtualizing their environments, with many achieving 90% virtualization rates and higher. Server consolidation and virtualization provides big business advantages including dynamic application environments, drastically increasing virtual servers with fractional hardware increases, and boosting application performance.
However, this rosy picture has its dark underside. One of the major challenges in growing virtualized environments is deciding between conventional backup and virtual-specific backup.
Conventional backup does in fact work for VMs and retains some advantages over virtualization-specific backup. Conventional backup administrators can extend existing backup interfaces and policies they use for physical servers. It grants granular recovery that a machine-image backup might not provide, it optimizes for specific applications, and administrators do not have to support two distinct backup products for their physical and virtual environments.
However, virtualized servers pose a unique problem to conventional backup: VMs are dynamic, not static. Once created they may remain for days, weeks or months – or minutes. It becomes very challenging backup reliably in this quickly changing environment. Resource contention is also a problem: the process-hungry and intensive data output of VMs makes conventional backup harder to operate with backup time limits. The inability to clone VMs using conventional backup software is another shortcoming.
Virtual-specific backup can solve these problems by minimizing resource contention, accelerating backup speed and cloning VMs. But it is not a perfect solution, and can have issues around deduplication, granular restore, and observing RPO and RTO for high priority applications.
Nothing is Perfect: Issues on Both Sides of the Backup Divide
Let’s take a closer look at some of these issues surrounding conventional and virtual-specific backup.
· Resource Contention. Physical and virtual environments differ radically in their average CPU utilization. Traditional physical servers operate at a comfortable 10-30% CPU utilization but virtualized servers will typically utilize 80% or more of their physical resources. .
This high utilization rate enables fast VM creation and performance but plays havoc with backup. The resulting resource contention becomes a real issue for VM performance and backup cycles. Installing an agent on the physical machine only, reserving server resources for the backup process, and/or and scheduling staggered backups for the VMs helps considerably. Virtual-only backup with its fast image backups will have much less of an issue with resource contention than conventional.
· Granular recovery. Conventional backup applications can restore granularly with a variety of restore options including file and folder, and sometimes server or object. But many virtual backups work using a fast snapshot technology to create a VM image. This works out beautifully for backup performance, when restoring an entire VM, or cloning VMs. It is not so beautiful when you need a granular restore.
Databases running on VMs have tight recovery point objectives (RPOs) and fast recovery time objectives (RTOs). Since most virtual-specific backup must restore entire VM images, this becomes an issue for service level requirements on high-priority applications. Some virtual-specific vendors can restore single files from the snapshot and many are working towards it, but this is not yet a universal feature.
· Treating VMs as separate backup sources. Most conventional backup administrators must install backup agents on each VM. This becomes a major obstacle to backup performance in large and dynamic virtual environments. Economics come into play too, with many backup vendors pricing per server license – not just the underlying physical server but every VM using that backup software. And this VM-centric backup process initiates separate backup for each VM; hardly a good use of limited CPU resources.
· Dynamic virtual environments. Dynamic VMs can also be a big challenge to conventional backup. Large installations with hundreds to thousands of dynamic VMs and dozens to hundreds of physical machines have their own issues with workload distribution, and backup can get very tricky. Backing up temporary VMs consumes resources, and backing up VMs that move between physical machines requires the ability to restore to the VM wherever it occurs.
· Backup storage capacity. Storage capacity poses a particular challenge for virtual-specific backup. Nearly all conventional backup products use dedupe to avoid backing up duplicate files or objects. But virtual backup usually reads the image file as a unique object not subject to dedupe, which quickly consumes backup tor capacity. The virtual snapshot is seen as a new file so it is backed up in its entirety, regardless of how much data has actually changed since the last snapshot. Vendors are working to add dedupe capabilities to virtual-specific backup but it is not yet widely available.