Do you remember the anticipation of the conclusion of the serialized stories you loved best? Maybe you waited with breathless anticipation for Harry Potter to finally defeat Lord Voldemort, for Luke Skywalker to defeat the Empire or to find out whether Michael Knight and KITT could save the day in any of the Knight Rider cliffhangers. While you may not feel the same tingle about the conclusion of this blog series, it cannot be any less coherent than the end of the Matrix Trilogy.
In prior posts, I talked about the importance of making the right choices, the challenges of providing scalable and efficient protection of VMs as well as some of the technologies (e.g., VMware Changed Block Tracking, versioned replicas, etc.) that IT folks need to be thinking about. But enough theory – what are companies really doing? Not surprisingly, the customers I’ve met have all chosen different approaches to protecting their VMs. However, despite the variations, there are two common themes: displacing tape with deduplicated disk and innovating to meet backup/recovery windows.
Over the next three posts, I will cover three different customer deployments.
Customer Story #1: From Storage-Based Replication to VMware CBT-Based Versioned Replication
Prior to joining EMC, I spent over a decade helping NetApp build its storage-based versioned replication suite (e.g., SnapMirror, SnapVault, Open Systems SnapVault, etc.). I worked with a variety of exceptional customers. At a recent conference, one of my more excitable former customers saw me, and shouted, “I replaced all your old stuff (i.e., SnapVault) with all your new stuff (i.e., EMC backup and recovery technology). It’s so much better!” To be honest, I wasn’t sure how to react. On the one hand, I was pleased my new company was able to improve his backup environment, but on the other hand, I had written much of the Snap code and none of the EMC code. (I quelled this threat to my ego by focusing on my wisdom in joining a group of people much smarter than me.)
Even without this riveting blog series, this customer had realized the potential of VMware CBT. Originally, he had provisioned VMs on FC-LUNs on FAS systems. He retained one week of nightly snapshots on the primary system and one month of nightly snapshots on a SnapVault secondary. He was thrilled with his backup performance and reliability, and had only three complaints about his environment:
- “Wasting” nearly 50% of space on the primary flexvol because he would not implement thin provisioning (fractional reservation < 100) and could not support automatically deleting snapshots (they were his backups, after all). He feared that he would run out of capacity and bring down his VMs. Without thin provisioning, his first snapshot reserved half the space on his flexvols to ensure that he could overwrite every block in the LUN without failure.
- Single VM recovery was complex and inefficient, since he could not put each VM in its own LUN, much less its own flexvol.
- Granular recovery from the VMs was complex and inefficient.
With the release of VMware’s Changed Block Tracking (CBT), his deployment strategy changed. He opted to use Avamar 6.0 to run raw VM backups with VMware CBT directly to Data Domain systems, where he retains each nightly backup for a month. His entire environment backs up within 15 minutes with stellar success rates. (He told me, “I ain’t gonna jinx myself by saying 100% success rates. You can’t make me do it. So stop trying. Just stop.” Of course, at this point, I hadn’t said a word in 10 minutes.)
He has successfully rolled back a VM to a prior night’s backup, using Avamar’s Changed Block Recovery, restored a VM to a new location and extracted a variety of spreadsheets and documents from the backups. While he has been thrilled with the performance, simplicity, and security of the Avamar solution, its cost-savings capability was clearly the highlight. “It’s saved me more money than anything else I’ve done all year,” he proclaimed.
He was able to:
- Regain 50% of his FAS capacity by embracing thin provisioning. He still uses snapshots, but since they’re not “official” backups, he’s enabled automatic snapshot deletion to free up space for the VMs, if necessary.
- Repurpose the SnapVault secondary FAS as a primary storage system.
- Reduce the size of the backups by 3x (the additional space savings provided by Data Domain’s compression and variable-length deduplication vs. NetApp’s snapshots and deduplication).
- Reduce network bandwidth consumption by 1.5x – less data means less bandwidth required.
Not only did the Data Domain systems pay for themselves, but the savings funded a separate project to protect his mainframe environment (and this isn’t the first time I’ve seen VM optimizations fund mainframes – who knew?). He now has backup storage for 3 years, primary storage for 2 years, and bandwidth for the next 12 months. This was not a three-year ROI – it was immediate.
In the next post, we’ll examine a customer implementing VMware-versioned replication in a way that blends brute force with subtle elegance (think either of the dancing hippos in Fantasia or Chris Farley as a Chippendale on SNL).
