A Comprehensive Misunderstanding

Data Domain is at it again: they have made another plea to please, please (please!) think of them as an enterprise solution. And boy are they ready to do disaster recovery. Honest.

Except that what they call disaster recovery, well, isn't.

Not by a long shot.

Now I am not sure if I care if they don't get it. Bummer for them, but ultimately, so what?

Well the so what in this case is I think they are unfairly dumbing down the collective discussion on backup and disaster recovery. In other words, they can make whatever claims they want, but when they attempt to redefine common understandings of backup and recovery and disaster recovery, in such a way that these terms mean less than they did before, they are doing themselves and the market a huge disservice.

Not that I am terribly surprised. When all you have is a hammer, every problem becomes a nail.

So when Mr. Budianski claims in this post that the Data Domain Replicator is a disaster recovery solution, I have to say I don't agree. Specifically, his claim is that: "Time-to-DR ... is the period of time measured from the start of the first job in the backup window to the completion of replication for all jobs. The high-level steps that make up the process measured by the time-to-DR metric are:

1. Full backup
2. Replication
3. Data consistent and readable from replica"

In other words, you have disaster recovery when you have finished replicating your backup data.

But that isn't remotely close to what disaster recovery is.

And there is no need to take my word for it. The SNIA definition of disaster recovery is: "The recovery of data, access to data and associated processing through a comprehensive process of setting up a redundant site (equipment and work space) with recovery of operational data to continue business operations after a loss of use of all or part of a data center... This involves not only an essential set of data but also an essential set of all the hardware and software to continue processing of that data and business. Any disaster recovery may involve some amount of down time."

So the essence here is that disaster recovery involves the recovery of operational data. Not backup data. And I need the essential hardware and software and processes to continue running the business.

Replicating your backup data may be an important first step in the recovery of operational data. But it is in no way shape or form equivalent to the recovery of operational data.

And this is a really important distinction. Because honestly any architect, or system admin, or IT person who tells their CIO or CFO or board that because they have replicated their backup data they "have" disaster recovery probably should start to work hard on their resume. Harder than they did on understanding disaster recovery.

Because disaster recovery means I can get my business (and the applications that power it) running again. Replicating backups doesn't do that.

What else do I need?

I need hardware. I need software. (Those may both seem obvious, but do you have a documented and tested process to identify what licenses you need, and make sure the license keys are available at the recovery site?) I need a backup server with which to initiate restores. I need a backup server catalog or database so that when I reference my replicated backup data set I know what is there. How are you replicating this catalog? Or do you have to restore it? What process is there for rebuilding the backup environment so that you can begin to restore data? Has your backup administrator documented this process, and made this documentation available and accessible to others? Where am I going to restore data to? And how am I going to restore application server binaries and settings? And so on, and so forth.

Now I am no disaster recovery guru. There are people that devote their careers to that. But I would bet that many of them would be as insulted as I was by the notion that replicated backups are equivalent to disaster recovery.

And the issue is ultimately this: by labeling backup replication "disaster recovery" you are doing a disservice to your business. Because if that is all you are doing, you don't have "disaster recovery".

And by attempting to pass off backup replication as disaster recovery, Data Domain is doing a disservice to us all by unjustifiably shrinking the scope and meaning of disaster recovery.

If everybody bought into this truncated notion of disaster recovery, nobody would actually be able to recover their business after a disaster. And that strikes me as a little senseless. Just like Data Domain's position.

PS: I was going to take exception to the notion that Data Domain is "enterprise ready", but I didn't. Because "enterprise ready" is pretty subjective. And who am I to say that their point product doesn't meet whatever subjective definition somebody might have for "enterprise ready." Having said that, is Xyratex disk enterprise ready? Who? Xyratex, of course! Is their storage 99.999% available like Clariion? Who knows, but they must be "enterprise ready," Right? ... Right?

Comments

[W. Curtis Preston]

Scott,

I've read and re-read Daniel's post and I just don't see him saying what you're saying he said. He did refer to dedupe replication as "a DR solution," but do you really think that this means that he thinks that it's the only thing you need for DR? Come on, Scott. You can't possibly think that Daniel thinks you don't need servers to recover to, or that you're done with DR as soon as you replicate. I don't read anything in his post to suggest that. He even said that this post was aimed at those "using deduplication to enable offsite disaster recovery." Seems to me that he understands that his "solution" ENABLES DR, it doesn't EQUAL DR. If this post says that he thinks these things, then EMC thinks the same thing, since they refer to NetWorker as "the first complete solution for backup and recovery of Hyper-V." (See http://www.emc.com/collateral/software/solution-overview/h4557-networker-hyper-v-so.pdf ) So are you telling me that EMC thinks that you don't need a Hyper-V server to recover to, or disks or tapes to backup to and recover from? You don't need any Fibre Channel, Ethernet, or backup server? All you need is NetWorker, right? It is, after all, a "the first complete solution for backup and recovery of Hyper-V."

He never said anything like "you have disaster recovery when you have finished replicating your backup data," or that replication was "equivalent to recovering your operational data." He also never said anything like "because they have replicated their backup data they have disaster recovery." What I DO see him saying is that IF you're going to use replication for DR, and the replicated copy of your data is your SOURCE for said recovery, then you don't have disaster recovery until you have finished replicating your backup data.

How could you possibly argue with that statement?

[Scott Waterhouse]

I dunno Curtis. Doesn't really seem like much of a stretch to me. They call it "time to DR". Not time to be DR ready. They call it a solution, which implies a completeness or comprehensive character. They don't show any sign whatsoever in this blog or the previous one (which I discussed in my previous post) that they understand, appreciate, or are prepared to discuss any of the larger issues--or even the basic ones like integration with backup applications. Their discussion is exactly what I would expect from a vendor that wants to flog boxes and nothing more. I think I will stick with my response.

[W. Curtis Preston]

They don't call it "Time to DR ready" cause that would be a silly term. We've used the term "time-to-data" for years in the backup biz to talk about how quickly (or not) certain tape drives can get to the BEGINNING of the backup and be ready to start reading it. No one seems to think that this means that as soon as the tape is loaded your restore is done, so how does the term "time-to-DR" mean that?

So EMC can call NetWorker a solution, and it doesn't mean that they don't understand larger issues, but if he calls his system a solution, then it DOES mean it. (Are you choosing to ignore that he also said it was merely an ENABLER of DR, which DOES show that he DOES understand that it's just one part of the whole?).

And you haven't answered my question. I think a reasonable person (who isn't just trying to make their competitor look bad) reading his post would think that he's saying that you can't start your DR until replication is done. The question is how can you argue with that?

[Scott Waterhouse]

Huh. So there was a perfectly good term already available and they chose a misleading one? (I have always referred to it as "time to first byte" FWIW.)

I don't think that I am trying to make them look bad. I think that he and Tony are doing a great job of that all by themselves. I don't argue with your vastly more charitable reading of the post, but that is not how it read to me.

Further, this whole blogging thing is supposed to be an opportunity for discussion and exploration of a topic (in greater depth than you would find in a marketing brochure). So if they actually did mean any of what you are ascribing to them, why didn't either Daniel or Tony actually write about it?

Let's face it: replication != DR. And only DD is trying to claim it is.

[W. Curtis Preston]

Maybe they didn't know said term. I actually googled it and didn't find it. I do know that it's in the index of the industry's leading book on backup & recovery: http://tinyurl.com/cqqwq5

I was fine until your last sentence. HE NEVER SAID REPLICATION = DR.

He said that if you're going to use replication to ENABLE DR (his words), then how fast that replication IS matters. And, AGAIN, how can you argue with that?

I have theories on your question about them not responding. Suffice it to say that lack of reply on their part does not constitute guilt in my opinion.

Now, do I think that DD salespeople often minimize/ignore the difficulty associated with recovering from replicated copies of backups? Absolutely. But that still doesn't change what Daniel is saying: If it DOESN'T get replicated, then NOTHING'S going to work.