In contrast, deduplication schemes that focus solely on local systems will transfer the same unique data segments on every full backup from every system that contains those segments. In the Avamar data deduplication process, a unique data segment is sent to the server only once, no matter how many clients contain that segment. Moreover, the Avamar server maintains all segment meta data to remain entirely independent of client systems.
In a VMware VI, Avamar provides two backup options for virtual machines (VMs) that can be utilized in tandem. The primary option for IT is to utilize Avamar for VMware image backup and restore, which employs a Linux-based appliance as a proxy VM client to leverage the VMware vStorage API for Data Protection (VADP). The alternative option is to install an Avamar agent directly on a VM guest operating system.
The proxy VM client follows the popular VMware OVF appliance model for image backup and restore operations by employing a SCSI hot-add operation to mount any datastore available to the ESX host and the Changed Block Tracking (CBT) mechanism to further leverage data transfer and capacity optimizations. For efficient centralized management of backup and restore jobs, the proxy VM client software interfaces directly with vCenter Server. In this way, Avamar provides IT administrators with the ability to restore a full VM, specific virtual disks of a VM, or individual folders and files of Microsoft Windows and Linux Guest VMs
Unlike many enterprise data protection packages, Avamar architecture provides the ability to run CBT-based backups in perpetuity. Every Avamar backup is a full backup. In contrast, both CommVault and Symantec require running either a synthetic full backup or a full VM backup without CBT every two weeks.
More importantly for CIOs, backup scalability, through its relationship with VM density, plays a key supporting role in maximizing the Return on Investment (ROI) from a VI initiative. Two essential elements for a high rate of return on a VI initiative are maximized resource utilization and minimized IT management costs. Both of these factors have a synergistic relationship with VM density on a host. In particular, driving up the number of VMs running on a host directly increases resource utilization. Furthermore, increasing the number of VMs without increasing the number of installed hypervisors, also limits the impact on VI management overhead for IT workloads. As a result, inefficient backup scaling has a direct negative impact on VM density by lowering resource utilization and raising IT management costs.
The Avamar client/server paradigm also provides significant advantages when dealing with Disaster Recovery (DR) and business continuity issues. For a business continuity SLA, ISO 22301 defines a Recovery Point Objective (RPO) and a Recovery Time Objective (RTO), which limit the acceptable amount of data lost and the length of time taken to recover from a downtime event, will be critical elements. The Avamar paradigm helps IT meet and support aggressive implementations of both objectives.
The proxy VM in Avamar for VMware utilizes the direct communications link established between the Avamar client and server to support CBT and data deduplication to efficiently minimize every backup window. Furthermore, communications between these two entities enables true global deduplication of data on the client. With the Avamar proxy VM client supporting CBT and global deduplication, the amount of data transferred in Avamar’s backup is guaranteed to be a minimum amount, which minimizes the time performing a backup and is the key to providing a short RPO.
Every Avamar proxy VM client backup also includes CBT meta data, which the Avamar server stores and links to every recovery. By setting up a communications link between an Avamar client and server during a restore process, the client and backup server are able to analyze the current CBT data for the client in conjunction with the CBT data stored with a recovery point to explicitly determine which client data has changed since the recovery point was processed. In this way, Avamar is able to restore just the data that has changed since the recovery point was saved.
In what can be thought of as an “incremental restore,” an Avamar CBT-based Recovery reduces the amount of data transferred in a recovery operation from potentially hundreds of gigabytes to hundreds—if not tens—of megabytes. More importantly, Avamar’s process of minimizing the data transferred in a restore operation is most efficient when the elapsed time from the recovery point is minimized, which means that an IT strategy that provides an optimal RPO automatically provides an optimal RTO with Avamar.
Performance Test Validation
To test the efficiency and performance of Avamar in a VI, three VM servers running Windows Server 2008 R2 were set up. One VM server was configured as a primary domain controller running Active Directory. The remaining two servers were configured as an Exchange 2010 high availability group using the Database Availability Group (DAG) construct rather than server clustering.
To host the VMware VI for the data protection tests, two Cisco UCS C200 Servers were used running ESXi hypervisors. Each C200 Server was provisioned with two quad- core CPUs. All storage for the C200 servers was provisioned from an EMC VNX Series 5300 array in a single disk-processor enclosure. SAN fabric topology was configured as a 10GbE Fibre Channel over Ethernet (FCOE) converged SAN. More importantly, all backup tasks were conducted in a hardware neutral manner. No attempt was made to leverage any of the advanced hardware capabilities of the VNX array to bias backup performance.