Synchronizing RTO With RPO
A key benefit CIOs cite for implementing a Virtual Infrastructure is the ability to leverage VI capabilities, such as rapid VM restart, non-disruptive VM moves, and VM cloning, to assuage the down-time fears of corporate executives. That makes a highly flexible VI a necessary component of any IT arsenal; however, a VI alone is not sufficient to resolve all of the knotty IT issues related to the most critical component of business continuity: data recovery. In a business continuity context, backup is simply a means to an end. For any CIO the main concern is recovery.
VM backup solutions now universally leverage CBT-based backups, which minimize backup time and support shorter RPO targets to minimize the amount of processed data that will likely be lost when recovering from a computer outage. Nonetheless, the work to provide an aggressive RPO can be quickly negated by a prolonged recovery process. Fast backup must be complemented with reliable accelerated recovery technologies to support an aggressive RTO, which must be measured in minutes for critical business applications.
Avamar uniquely addresses the process of restoring any VM to any recovery point by leveraging the CBT meta data saved with each VM backup to implement a CBT-based Recovery. Using the CBT meta data maintained in the Avamar Data Store and the current CBT data on the target VM, the Avamar VM Proxy Client and Data Store coordinate the minimum set of blocks needed to restore a VM to a desired recovery point. In sharp contrast, the other solutions needed to transfer all of the data present at the time of the recovery point. What’s more, all of the data involved in these restore operations must be processed using the hypervisor, which forces all data transfers to occur over an Ethernet connection.
For supporting an aggressive RTO, the Avamar CBT-driven restore operation was unparalleled. Restore tests of the Exchange VM began with a series of 2% and 5% changes to the Exchange mailbox database using LoadGen that were followed by a CBT-based backup in order to create a set of recovery points. To test restore capabilities, two recovery points were chosen. The first recovery point was associated with the most recent backup, which represented a 2% change in the maibox database. In addition, an older 5% change point was also chosen for recovery.
In each case, Avamar CBT-based recovery was dramatically faster than either CommVault Simpana or Symantec NetBackup. Not surprisingly, the differential in recovery time was greatest for more recent backups, as less data needs to be transferred and calculation of a minimal set of data is less complicated. In particular, the advantage that CBT-based recovery brings to IT is maximized when both the rate of change and the time elapsed since the recovery point are minimized. As a result, IT ensures an optimal RTO with Avamar simply by using backup operations that provide an optimal RPO.
Specifically, restoring the most recent recovery point with Avamar took just two minutes. CommVault Simpana took 141.5X the time taken by
Avamar and Symantec NetBackup took 27.5X the time taken by Avamar. For an older recovery point, which at the time represented a 5% change in the mailbox database, Avamar took 16 minutes—8X the running time of the most recent change. Nonetheless, ComVault Simpana took 19.75X the Avamar run time and Symantec NetBackup took 4.06X the Avamar run time.
In addition to the time to run a restore operation, the network efficiency of a restore operation, represented by average network throughput over the time taken by the restore process, was also examined. In particular, the area under the graph of throughput over time gives a measure of the work performed during the backup process and equates to the amount of data transferred in the process. Using this measure of network efficiency, Symantec NetBackup transferred 52X the amount of data over the LAN as Avamar and CommVault Simpana transferred 410.8X the data transferred by Avamar.
