The Backup Blog

The Next Step Forward For Mainframe Virtual Tape: DLm6000

Mainframe tape is a funny thing. Or at least it can look funny to a person that doesn't work with mainframes.

Funny because mainframe tape does a bunch of things. In the open systems world, life is simple by comparison. Tape does (or did!) basically one thing: backup. Yes, you could argue that it was used for archiving too, but that argument largely depends on the notion that backup and archive tend to be the same thing for open systems folks. Which isn't necessarily a good thing, but it is certainly the case more often than not.

In the mainframe world however, tape does at least four things: backup, archive, batch processing, and migration (for DFHSM). Now some of these, it could be argued, are sort of suited to tape. And some are not. In fact, as time has moved on, the value of tape to each of these has degraded.

And as innovation has occurred, that value has degraded even further. Because mainframe tape is very much like open system tape in one key respect: it isn't very much fun. It is unreliable (relative to other IT systems), it is insecure, it is slow, and it is an operational nightmare. And on top of it all, it makes disaster recovery planning, testing, and execution really really difficult.

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?

The Remote Office: CDP or Backup?

A colleague sent me the following link the other day: The Case Against Tape Backup. The link gets you to a white paper written by Double Take Software, which argues that using tape for remote office backup is a bad idea.

Their conclusion? That instead of tape, we should employ CDP software, and that this is much more cost effective.

Unfortunately the paper is deeply flawed. Don't get me wrong, I would be very happy if the general conclusions they drew were true. I would be just as happy if they were content to conclude only that tape was bad--meaning too expensive and too unreliable. 

However, they are not content to reach such a conclusion, and in their attempt to make the leap from "tape is bad" to "CDP is good" they go dramatically awry in two respects. First, they posit a false dichotomy. It is not like the only alternative to tape is CDP for remote backup. And, in fact, some of the solutions that they (conveniently) ignore, are substantially less expensive than their proposed CDP solution. Second, their financial reasoning is pretty badly flawed. And I have never been a fan of make your own solution look good by falsely making the alternative solution look bad.

However, I do think that following through the line of reasoning in the white paper is pretty interesting--and by doing so we can expose some better data about the costs of remote office backup and the alternatives to tape.

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.

Actual Deduplication Ratios

Or, does deduplication give you what you want?

I thought it would be an interesting exercise to try to correlate the voting in my poll (in the right hand column) with the actual results achieved by deduplication users. This should give us some indication of whether the technology is meeting the expectations of users.

So, after 199 votes, the results are in. The results were pretty consistent by geographic region, with about 2/3 of the votes coming from the USA (which pretty closely mirrors world-wide adoption of deduplication technologies).

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.

Backup and the Downturn

I haven't talked about the downturn at all, because, well, a) it is just depressing, and b) there doesn't seem to be much point. However, I did see an interesting article over at Search Storage that mentions that backup is the last service likely to be touched or impacted negatively by spending cuts.

I guess that is good news for those of us that have specialized in the area. Anecdotally, I can vouch that I have been no less busy for the last couple of quarters than I have been in previous years during year end. If anybody has any experiences to share in that regard, please post up. It would be interesting to build a picture of our backup and recovery industry from participants that would show how much (or how little) the current economic slowdown is impacting us.

Deduplication and Replication

Some time ago I wrote a post Peace, Love and Revolution about the issues that replicating deduplication appliances causes with backup applications. Some six months later, I thought it would be good to update the state of the nation and see what progress has been made.

To quickly refresh, the issue is this: how do you restore data from a deduplication appliance that is the target for replication--when it is the appliances that is managing the replication process and not the backup application. (And to be fair, this is not an issue unique to deduplication: the exact same problems apply if you are just using virtual tape. The issue just happens to be more pressing with deduplication because if it is "just" virtual tape, I can use the backup application to manage replication and not cost myself any bandwidth; with deduplication, if I use the backup application I miss out on the 95% bandwidth savings that deduplication replication promises.)

So They Do Understand...

It took a while, but the nice folks over at NetApp have attempted to describe what exactly Tape Smart Sizing does. I could be wrong, but I think they agree with me. I guess since I agreed with them that using single parity RAID on a VTL with 1 TB drives is dangerous (yes their Near Store VTL does exactly that...) they decided to return the favor? Perhaps...

In any event, Absolute Architect decided to pen a response which was completely complementary to my analysis. To the best of my understanding, she agrees that Tape Smart Sizing is a "confusing ... technology that won't remotely impact your life" (her words). Which pretty closely echoes my claim that it is "unnecessary and irrelevant". And I mean that literally. For most, if not all organizations, the "feature" is either unnecessary, irrelevant, or both.

Much like a square wheel bike.

Do square wheels work? Yes, if the ground is shaped like an inverted catenary. Are square wheels necessary or relevant? Not even remotely.

The analogy is perfect. Does Tape Smart sizing work? Yes. Is Tape Smart Sizing necessary or relevant? Not even remotely.

The good stuff is always in the why.