The Backup Blog

A Data Protection Taxonomy

Building on the notion of a revised data protection and backup methodology described in my previous post, I think there is another important notion here: that of a data protection taxonomy.

As we think about moving backup away from a host-centric application, to a data-centric service, I think we need a way to consistently describe the data protection characteristics of a data set. This description needs to be completely independent of any storage array, application, data type, vendor, target, or network.

We need a simple, consistent means of sharing an entire data protection policy between any device or application responsible for providing data protection services.

I could then associate the data protection policy with a data set and any service provider for data protection could interpret it, and provide the mandated service level.

Basically, any data object could have such a policy associated with it. And I could bind that policy to it in all kinds of interesting places.

How about binding a policy to a VM and making it available through the APIs on ESX or VSphere? How about binding a policy to a database and making it available through the Oracle APIs? How about binding a policy to an OS? Better yet, how about binding it to a consistency group or LUN on an array?

At this point, with the appropriate credentials, any data protection service provider--be it archival services, Continuous Data Protection (CDP) services, backup services (hosted on an appliance, an array, in a traditional backup application)--can read or request the policy, and provide the required data protection service.

More practically: any service provider, from any vendor can act upon any data set, resident upon any storage.

How is that for no more vendor lock in?

How Backup Is Broken

What will backup in the cloud look like? Chuck Hollis wrote a post a few weeks ago on the subject.

I have been thinking about the issues that he raised ever since. Mostly because there was something about the piece that didn't quite satisfy me. There was something missing. Something that I couldn't put my finger on at first.

So I asked a more fundamental question: why do we backup like we do today?

And the only good answer I could come up with was: because that is the way we have always done it.

And I really don't like that answer.

In and of itself it is almost never a good answer. It may be that we have always done it that way, and there are good reasons for doing it that way. But if we are just doing it because we have always done it, and there is no other reason, that isn't good enough.

Not when the process is so badly broken.

Make no mistake: backup today is broken. Badly broken. It involves too many pieces. Too many components of the infrastructure. Has too many dependencies. Takes too much administrative effort. Takes too long. And it doesn't do a very good job of leveraging new technologies.

All because we take a host-centric view of backup.

Why Would You Want To Be An EMC Employee?

Joe Tucci's open letter to Data Domain employees go me to thinking: what is so great about EMC? And why did I choose to work here (and why have I have chosen to remain)? What would a Data Domain employee want to come to EMC? Why would anybody?

So I thought I would give a few of my own observations. The sample size is me. I am not going to say a single thing about their alternative, NetApp, because I have never worked there. This is just about what makes EMC, in my opinion, such a great place to work.

Putting The Pieces Together: Deduplication Technologies

Disclaimer: everything that follows is my opinion. In no way should it be mistaken for any sort of official EMC position. Any resemblance to that is purely coincidental.

Amidst the chaos and confusion of the EMC offer to buy Data Domain, I think the biggest unanswered question has been: why would EMC want to have three or four or five different deduplication technologies?

Truthfully, I think the question has a profoundly simple answer: because backup sucks.

Mmmm, irony.

Don't believe me? Show of hands: how many people actually like their existing backup application?

Given the name of this blog, and that I have spent the last 15 years plus on backup and recovery, I think I can appreciate the irony as well as any.

Even more ironic when we remember that Data Domain's original slogan was: tape sucks.

And by the way, there is a back handed answer in there as to why it makes sense for Data Domain to be acquired by somebody. If you claim that tape sucks, and you try to "fix" this with another piece of hardware, all you are really doing is building a better tape drive. You are trying to be StorageTek, only better. Where better means faster and cheaper. But does a faster and cheaper tape drive make backup suck less? Maybe. But probably not nearly as much as it could--if you had a broader perspective and reach with your technology roadmap, one that includes CDP, primary storage, a backup application, and some virtualization capability. More on what I would do with all that later. But one final question: if your objective is to fix backup, completely, and you think that you need access to all those components to do that, who is going to be in a better position to do this? EMC? Or NetApp?

Having said that, the biggest obstacle to fixing backup is not technology. It is inertia. It is cultural. It is fear of change. It is ingrained process. It is the fact that we have done things one way for so long that the reason we are going things has been forgotten.

EMC Counters NetApp Offer

And other than stating the obvious that EMC did, in fact, counter NetApp's offer for Data Domain, I am not going to make any further comment--for the simple reason that I have no desire to run afoul of our very sharp legal team! I will leave the comments section open here and under the R.I.P. Data Domain post below for any general discussion--as long as it doesn't devolve into anything inappropriate. For those of you looking to read any additional commentary, I would recommend Chuck's Blog or the Storage Anarchist.