The Backup Blog

Tape and Deduplication

I just saw an interesting article by Chris Mellor over at The Register. Chris was speculating on why we haven't seen any deduplicated backup on tape. Because, hey, if I can squeeze 20 times as much data on a disk using deduplication technology, doing so on tape has to be a good thing, right?

And it would allow tape vendors to show that the technology has some relevance beyond long term archiving.

Chris has a lot of good explanations as to why we don't have dedup on tape yet—except from CommVault and EMC. But he misses the biggest reason of all: it might be really good for backup, but it is horrible beyond belief when it comes to restore. And as myself, David Chapa, and every other backup specialist will tell you, it is all about restore.

Why is it so terrible? Seek time.

Killing Me Softly

Early this week an IBM blogger mentioned that IBM had increased the density of storage on tape by some impressive factor of 40x or thereabouts that would result in tape cartridges of 35 TB. As a research exercise or proof of concept or some such thing.

Consider me unimpressed. Well, no, not quite. I am impressed in the same way that I might be if I took a trip to the Ripley's Believe It Or Not exhibit at the circus. Weird. Bizarre. Freaky. But not terribly useful to the real world.

I also had two more rational reactions.

The first of these was that the "announcement" reminded me a lot of a briefing that I attended many years ago. The briefing was given by Sun, and it was all about their new multi-core, multi-threaded processors.This was a big thing at the time: Sun had been selling some really really big systems (E10000s and E15000s for those of you with long memories). And they were really really expensive. Yes they occasionally went out the door at 90% discounts. But often these systems were $10,000,000 or so. Just for the system. No storage. No apps. No database. Which seems pretty absurd by today's standards, doesn't it?

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.

Backup Service Catalog

My previous post Is a Copy a Backup? was written after I got to thinking about a backup services catalog. What is a backup services catalog? Basically it is two things.

First, it is an admission that we have a lot more choices in terms of what technologies to use to provision backup services than ever before. 10 years ago, the backup technologies was really backup technology: tape. It was pretty easy to design a such a catalog, because you really only had one choice: tape. And it didn't really matter how rich, thin, or beautiful you were, you still only had one choice: tape.

Second, it is a recognition than different applications have different levels of importance to the business, and that given we have an array of technology choices with which to backup them up and recover them, we should probably choose different technologies for the different applications. Let me put that a different way: your SAP/Oracle application which runs AP, AR, and inventory is probably way more important than a miscellaneous SQL server some user threw up for ad hoc reporting, or an edge web server that is one of a few dozen others just like it.

So if you have different tiers of applications, shouldn't you have different tiers of backup and recovery? You bet you should.

Web Demos of EMC Backup, Recovery, and Archive Products

For a while now the good folks at Avamar have been offering once a week demonstrations of the product via webex. The schedule has now expanded to include some of the other products in our backup, recovery, and archiving solution set.

The schedule is now as follows:

Times	Monday	Tuesday	Wednesday	Thursday	Friday
8:00 –9:30 am (pacific)	HomeBase (bare metal recovery)	EmailXtender (email archiving)	NetWorker (backup and recovery)	RepliStor (remote file replication)	Avamvar (source based dedup)
10:00-11:30 (pacific)				Data Protection Advisor (backup reporting and analysis)

Complete URLs, dial-in numbers, and product details can be found below. You can also find longer descriptions and product links below.

Deduplication APIs?

Curtis Preston raised an interesting point over at Backup Central regarding the need for a common set of standards for the interaction of deduplication appliances and backup applications.

Now, on one hand I agree with Curtis' basic premise (even if I do slightly disagree with some of his historical characterizations). In fact, I have twice made pleas on this blog to similar effect, here and here. Having said that, I will readily admit that W. Curtis Preston is taking the request to the next level. Rather than just ask backup application vendors to implement the means to take advantage of the target side replica of a deduplication appliance, he is asking to community to have a common set of APIs, an open standard, around this.

So, a couple of things. First: everything in this post is strictly my opinion. Nothing in here has been read, endorsed, or reviewed by anybody else at EMC. Having said that: Mr. Preston is right. This is needed, and needed badly. I have been saying it for a while, and his request is the logical extension of the arguments I have made before. So rather than arguing with Curtis about history or debating how to do this, let me state clearly which I think such an effort should achieve, with the hope that this can constructively advance the conversation.

DeDup Ratios and Fixing Backup

Normally, very high deduplication ratios are something to be pretty excited about. Particularly if you are the one getting them. If you get 450:1 deduplication, you are probably a pretty happy camper. It probably means you have saved yourself a pile of time, money, and administrative effort. It probably means your TCO is lower, your risk is reduced, and your backups are a lot more reliable.

So, life is good, right?

Well, maybe. But maybe not. Sometimes extravagantly high deduplication ratios are a sign that something is wrong. Really wrong.

I want to take the opportunity to talk about why, if you are getting 450:1 deduplication ratios, you may want to make some changes.

SAP Archiving Videos

I thought I would depart from the discussion of backup and VTL for a moment to address the other side of the backup, recovery, and archive coin: archive.

Here is the neat thing about archiving: it almost always makes sense. There is almost no situation in which (if you have a sufficiently large amount of data) archiving doesn't make financial sense. Even if you deduplicate all your backups, it is still usually better to archive it--that way you don't have to back it up at all!

By the way, the sufficiently large is just a caveat to ensure that we are not talking about solving a $5,000 problem with $4,000,000 worth of technology. Otherwise known as opening a mailbox with a hand grenade. And of course there is a second caveat here: the data has to be archived to a destination that doesn't require backup, by virtual of the technical characteristics of that destination. Centera fits that description. If there are other platforms that do (and that still make good sense--ummm, Plasmon, sit back down please, that doesn't mean you...) I will happily add them to my list.

Tape: Dead or Alive?

Tape is dead.

Tape is not dead. The market for tape is growing.

Those are the two contradictory stances that pundits and analysts have been advocating for a while.

A few of those analysts and pundits like to point at EMC and say "you said tape is dead!" and it isn't. Sometimes they leave the conclusion ("you guys aren't very bright") implicit. Sometimes they don't. Sometimes their conclusion is considerably less kind than "not very bright."

My own position has been (for the last couple of years) that tape is not dead, but that the role of tape will significantly shrink, and that it will become primarily a medium for archive. For primary backup and restore, the proverbial fat lady has sung. Or if she hasn't done her aria yet, you can certainly hear her warming up her vocal cords back stage.

As always, the thing that dismays me most about these debates is the blatant use of misleading materials, flawed analyses, myths rather than facts, and hysteria rather than reasoned analysis. The latest example of this lack of reasoning can be found coming from HP: under the illuminating title of "The Real Story About Tape Storage".

But lets look a little closer at the real story.

I think is about as real as Alice's trip into Wonderland.

NetApp's Compliance Isn't Compliant

I came across an interesting tidbit from the NetApp camp today.

It seems their version of compliant archival storage, isn't, well... compliant.

A brief background: archival storage frequently is used to store data (email most prominently) that a regulatory body has determined that a company must keep. Mostly so massive evidence shredding a la Enron doesn't happen again.

You need special storage to meet these requirements (from the SEC, Sarbanes-Oxley, and so on, as well as their respective counterparts in Europe and Asia). Normal file storage doesn't cut it.

EMC has met this need for nearly a decade with Centera. (In fact, there are 3 versions of Centera desinged to meet different compliances objectives.) NetApp has "Compliant SnapLock" and you can find similar umm, hacks, from other vendors.

And I call them hacks for a reason: EMC believes that compliant archival storage should, amongst other things, not have a file system that is exposed to the user. There are a bunch of characteristics I want to see for compliant archival storage, but that is one of the big ones. I am open to correction on this, but I think Centera is the only platform that actually does this.

Now, all this has come to bite NetApp in the proverbial posterior: "...versions of Data ONTAP® prior to 7.2.5 with SLC have been found to have vulnerabilities that could be exploited to circumvent the WORM retention capability." They go on to say: "NetApp cannot stand by the SnapLock user agreement unless the upgrade is performed."

Now this is a really big deal. This is not a trivial little upgrade to OnTAP. This is a big one. There is a reason why thousands of NetApp customers haven't made the lead yet: it is risky and and it hard.

In the words of NetApp themselves: "This upgrade is a one-way procedure."

So, anybody running a version of OnTAP older than 7.2.5 isn't compliant.

I hope you don't have any visits from the auditors scheduled in the next couple of months...

Or years...

Or maybe it is time to explore an alternative?