By Mike Zolla, Director, Corporate Systems Engineering, EMC Backup Recovery Systems Integrations Lab
What would you rather do recover 2GB or 500GB?
Recovery is the final end game – after all, it is the point of backing up. With Avamar, files can be recovered into a VM without the need for agents within the guest OS. But this is not the revolution. The revolution is about “changed block recovery,” or CBT restore, and Avamar is the only software that can do this. (For more of my thoughts on CBT, check out my previous posts.)
Here again, this is due to Avamar’s block-based architecture. By retaining a block as a block during the backup process, Avamar can re-scan the existing CBT reference file and compare it to the CBT information stored from the backup the administrator is recovering from, and only send back the blocks needed. This significantly reduces both the amount of data that needs to be recovered and the time to achieve full recovery.
Since other vendors’ solutions store the file, they have no way to convert a file back to a block and ensure where that block was within the VMDK at backup time, which means they don’t have a changed block recovery options. This means long restore times when doing an image recovery.
Proof Is in the Use Case
It is nice to have restore options, but they need to be practical or they are just a “check box” on a slide deck. So, let’s look at a real-world example.
Consider the scenario in which there’s an issue with 500GB SQL DB running in a VM. The SQL DB could be recovered with any backup software running within the guest OS, but the entire 500GB DB would need to be restored. However, with changed block recovery, if only 2GB have changed since the last backup, the VM would simply restore the blocks needed and get the VM restored and running in minutes. Avamar completes this without any background processes occurring after the VM is “recovered,” so there are no resources consumed from VMware ESX after that short process. Without this capability, backup software would have to recover either the full 500GB VMDK, or copy back the 500GB DB files to the VM and attach them.
It’s not just talk, check it out: http://www.youtube.com/watch?v=3YWh07A3Cxg.