Wednesday, May 5, 2010

A virtual machine (VM), from a storage perspective, is really a single file that encapsulates all the files in that server instance. When simply considering raw backups, VMs should simplify things, and from a recovery point of view, it is arguably much simpler to provision and restore a virtual machine than it is to do likewise in a physical environment. The problem is that VM files can get very large, and most customers are still uncomfortable backing up at the Image level, preferring instead to do guest backups.

The challenge with guest backups is that resources are more limited in a virtual environment, with multiple virtual servers all competing for a single physical server’s resources. Sending many large backup jobs simultaneously from a single host across the network can place a burden on the host server that does not have the resources to deal with it. This leads to two results.

First, schedules of VMs have to be very carefully balanced. This takes time and constant monitoring, which today’s lean IT staff doesn’t have. Second, it limits the number of VMs that can be placed on any given host server, no matter how powerful that server becomes. If only a certain number of VMs can be backed up at once, this limits how many VMs can be accommodated in a given backup window. Backup limitations like this are a top cause of reduced VM density, which lowers overall host utilization and the virtual infrastructure’s ROI.

Customers who have opted for image-level backups have typically been drawn by the lure of simple bare-metal recovery and disaster recovery. Image-level backup offers full VM system state restores. Image recovery can be fast, since it is from a large image file, rather than from many small files. And by offloading the image backup process onto a backup host, you can reduce overhead on the ESX server – which should mean less impact on performance for applications running there. On the down-side, file level recovery from image backups has typically been a multi-step process involving restoring the VM from the image backup, and then browsing for files. At present anyway, getting application consistent backups at the image-level is not straightforward but VMware is beginning to address this shortcoming.

Client side deduplication, like that used by EMC’s Avamar solution, may be an ideal way to improve virtual infrastructure data protection, and address challenges for both VM guest and for image-level backup.

Client-side deduplication differs from other forms of deduplication in that redundant data is identified before it is sent across the network. This can increase the load on the host CPU somewhat, but substantially reduces the load on the network. Because of the high level of redundant information in a virtual environment and the fact that the data is typically sent across a highly congested IP network, leveraging client-side deduplication has a lot of advantages.

For VM guest backups, client-side deduplication products like Avamar takes away the backup bottleneck caused by contention for shared resources (by eliminating redundant backup data), this approach really helps customers optimize consolidation ratios, increase VM density, and get the most out of their VMware investment.

For image-level backups look for client-side deduplication products that can take advantage of VMware’s vStorage API for data protection (VADP). The VADP approach involves creating VMware snapshots of a VM, presenting them to a proxy host – and then backing up the VMDK file from the proxy. Customers like this approach because it moves the backup process away from the VMs where their applications are running, and avoids any performance impact to the application. Make sure that the client-side deduplication product has the added ability to easily do file restores from image-level backups.

Scan time is a primary concern in any VMware backup discussion. This is the amount of time it takes for the backup application to examine the client for changes to data and compare to what has already been protected in previous backups. With VMware’s vSphere4 release much of this concern is addressed by improvements provided by the vStorage API for Data Protection. In particular the new changed block tracking (CBT) feature. CBT monitors the block changes that have occurred since the last backup. It does not keep a copy of the changed data, just a log that the blocks in question have changed. This is a huge help to backup technologies who typically have to determine what has changed via their own methods. This makes backup jobs (and replication) much quicker.

If the client-side deduplication product can leverage CBT for image-level backup the most important implication is that when processing the backup of large VMDK files, only the changed blocks need to be evaluated for duplicate content, which is a significant time saver. Under normal circumstances, any change to a VMDK would require the whole file to be re-scanned, but not with CBT. CBT support should be considered a must have for client-side deduplication products.

From a backup and recovery perspective, the backup administrator is now dealing with near ideal conditions. Client-side deduplication provides the equivalent of doing a full backup every night without having to suffer the corresponding data load on the network. The disk used for storing the backups is efficiently used, again, because of the deduplication. This leads to more space to store backups and the option for longer ‘on disk’ retention times.

Recoveries can be full-system or single-file and are fast, because they are disk based.  And since it takes advantage of CBT, its recovery advantages are amplified even further.

Replication to a remote facility is also easier and faster than traditional backup since only net-new segments are stored, and transferred across the WAN. When used with replication, client-side deduplication represents a complete backup and recovery option, even in the event of a site outage.

Client-side deduplication, such as Avamar’s, is best used in environments where bandwidth is thin, chances of redundant data is high and there is excess CPU on the backup client. This is the case in most virtualized environments. The net effect is that while there may be a slight spike in CPU utilization as the scan is being done, it’s negligible given the payoff; greatly reduced total backup windows when compared to traditional backup techniques.

George Crump, Senior Analyst