A recent post by somebody over at Data Domain's Dedupe Matters (Especially When That Is All You Do) Blog waxed enthusiastic about their ability to leverage deduplication for disaster recovery.
Reading through the post, I couldn't help but feel a little underwhelmed. The way the issue is discussed it reminds me more of Inspector Clouseau than Sherlock Holmes.
The analysis seemed to me to indicate that Data Domain is very much a hardware company struggling to understand the nuances of software, and the critical role operations and process play in a backup and recovery operation.
Digging a little deeper, the post claimed that using Data Domain appliances for disaster recovery is:
- Cost effective and efficient;
- Easier and offers faster recovery SLAs compared to primary storage replication
Now I will be the first to admit that I think that data deduplication for backup has two major attractions: reducing the amount of disk required to store backups, and reducing the amount of network traffic required to replicate backups.
Having said that, I think that Data Domain's position pretty badly misunderstands the process and operational components involved in using backup for disaster recovery. Further, I think their hardware only approach fails to deliver on the real promise of remote deduplication (for remote office sites).
Lets deal with them in that order. So how do we use backup for disaster recovery? Well, pretty obviously a deduplication appliance can replicate my (deduplicated) backups from one site to the other. That's great. But to claim this offers faster recovery than primary storage replication is ridiculous. Primary storage replication will always offer the fastest RTO of all our available options (with CDP, deduplicated and replicated disk, and traditional tape lagging, in more or less that order).
Because to recover something from replicated, deduplicated disk, I have to:
- Build or have a standby backup server
- Install an OS and my backup application on that server
- Restore my backup catalog or database
- Re-attach my deduplicated disk and make "check-in" the volumes to make them available
- Install a backup client on the server I wish to restore to
- Restore the data
More or less. Your mileage may vary slightly if you are using NetBackup OST or NetWorker PTT, but mostly in detail, not in any significant way. And let's note this is a time consuming process in total.
So I would like to make two comparisons here: one to primary storage replication, and the second to Avamar.
First, primary storage replication requires none of these steps. So by whatever amount of time you think you can accomplish those steps in, that is the amount of time you gain on your RTO with primary storage replication. Be it 4 hours, 8 hours, or 12 hours, you are just that much faster with primary storage replication. Honestly, I don't know what Data Domain is thinking, but this is just the case. (The only remotely plausible reason I can think of for why somebody would want to deny that this is the case is that they don't sell primary storage, and don't understand that backup is not just hardware, it is also software and process...)
Secondly, we can compare the above process to one using Avamar. The steps with Avamar would be:
- Restore the data
That's it. As the Avamar server replicates not just data but meta-data, and because it is both the application and the hardware, there is really nothing else to it. I don't need to rebuild anything, restore anything, rebuild a catalog or database. I am just ready to go.
Now, Avamar is still slower than primary storage replication because I still have to restore data. But it does offer a significantly faster RTO than Data Domain. How many faster? Well, put your own figures on steps 1 through 5, but I think you would probably be looking at 6-12 hours to accomplish all 5 steps.
In other words, not only does Data Domain not have a better RTO than primary storage replication, they also have a significant disadvantage to Avamar in terms of RTO for disaster recovery.
Secondly, Data Domain makes the claim that their approach is better (compared to what they don't say, but lets just assume they mean better than tape) because it is more cost effective and efficient for remote site backup.
Hrm. I don't think so. Again, this is a claim that just doesn't stand up to much scrutiny. Or, more accurately, it is true but irrelevant. It is like saying that they have a better way of bailing out a sinking boat: and rather than using their hands they are going to use a sponge.
The boat is still going to sink. Saying you are better than really really bad is nothing to brag about.
But there is a much better alternative: Avamar.
So why does Data Domain's approach fail to improve in any real way upon the use of remote tape: because they still need a backup server at that remote site (or a DSN or SMS) with all the licensing and management that implies, and they still need an appliance.
Lets contrast that with Avamar's approach. What do I need at the remote site: nothing but a client.
If I want something a little more robust, how about a virtual server? Or a single Avamar node? Both offer efficient ways to scale up from the client only approach. But only the third way (single node) actually requires any dedicated hardware at all at the remote site.
So it is possible to protect remote sites and offices far more efficiently than the method offered by Data Domain. Get ride of the remote application and hardware entirely: use Avamar.
But as long as Data Domain continues to focus on flogging boxes, and doesn't understand that backup is about a whole lot more than just that, I expect to continue to be underwhelmed.
P.S. To any Data Domain folks reading this: all rational comments welcomed, and don't forget to make me suffer!