The Backup Blog

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.

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).

Avamar Restore is Fast Too!

This is going to set a bit of a record for me for short posts, but I figured the data deserved better than to be buried in the comment section.

We recently had a customer compare Avamar to TSM. (A different customer than the one which provided the data on backup speeds and volumes detailed immediately below.) Two things emerged:

1. Network utilization was so low vs. TSM that they thought the measurement tool was broken.
2. Restore speeds were so fast vs. TSM that they didn't believe that restore had worked.

Upon further investigation we found that the tool wasn't broken. And the restores really did work.

Yes, this is a sample size of n=1. So it is not worth a lot statistically. But anecdotally, it is very interesting. And I would say that my observation in talking to a lot of folks that have deployed Avamar is that this is not an atypical case.

Do You Know How Much You Backup?

And another question, just as important: do you know what you backup?

To those who do know, the question may seem trivial--even insulting. Of course I know! But do you? Really?

Two recent cases make me think that some backup admins who think they know how much they are backing up, in fact, don't know.

Sort of a case of however much you think you are backing up I do not think you are backing up what you think you are backing up.

In each of these cases, the backup admin was off by about a factor of 3. One thought he was backing up about 1.5 TB per day. It is actually 4.7 TB per day (and climbing). Another was convinced that he was backing up about 2 TB per day. In that case, he actually backs up about 7 TB per day.

Avamar is Fast

Every time I speak in front of customers about Avamar, I emphasize how much faster it is, and how much less data it sends over the network, than competitive products.

In the end, I think most people end up believing that Avamar can reduce their network traffic by 99% or better.

But I think a lot of people are skeptical about my claim that backups are much faster. So here is another data point that I can offer as "proof". All end user names have been removed to protect the innocent, and a huge shout out to Keith Lawrence for putting the data together.

The comparison is to TSM. The datasets, clients, and so on, are identical in each case. Basically we ran the TSM client and the Avamar client back to back, and had a look at how much data each sent, and how long it took to complete the backup. There are two amazing things here: one, TSM only does progressive incrementals (no full backups) and it still gets smoked by Avamar in terms of how much data is transmitted. Two, again, these TSM backups are not full backups, but they still take much longer than Avamar.

Here are the results:

	TSM Data Sent	Avamar Data Sent	TSM Elapsed Time	Avamar Elapsed Time
Day 1	148.79 MB	15.36 MB	17:45.0	9:36.0
Day 2	149.41 MB	14.54 MB	37:58.0	9:35.0
Day 3	156.56 MB	14.70 MB	39:26.0	9:37.0

So, despite being matched against an incremental backup, Avamar still manages a 90% improvement in amount of data transmitted (and, correspondingly, network utilization). And it still manages to take approximately 25% of the time to finish a backup.

Avamar. Nitrous for your backup.

V-Max and Backup?

So the announcements have been made, and the cheering (or teeth-gnashing and tomato throwing if you are a competitor) have begun. Largely I didn't go there, personally, because... well... this is the Backup blog. Emphasis on backup. I like to stay true to the subject and theme because I think that is what my audience is interested in.

I subscribed to Chuck's advice in a round about sort of way: I didn't think I had much to say specific to V-Max and backup so I just didn't. (And, if you want to read about V-Max, then I would suggest starting with the Tolstoy of the subject, Barry, aka The Storage Anarchist. Barry is articulate, comprehensive to a fault, and has lots of interesting things to say. So much so that thank goodness we are not slaughtering trees to make these posts! Also making for interesting reading are posts from Storagezilla, Steve Todd, and Chad Sakac.)

Now I didn't say I had nothing to say--just not much.

So I would like to offer up a couple thoughts. Most of us will conclude that a new enterprise array like the V-Max doesn't have much to offer for backup. I am not so sure that is true any more.

Perhaps, due mostly to economics, people won't use the V-Max for backup. But take the economic component aside and I think there are two interesting dimensions to the annoucement.

DL4000 3D Explained, Part 3

In an effort to respond to the observations of W. Curtis Preston in his posts here, here and his comments here; and additionally in an effort to satisfy those of you who wanted a more direct response to those observations, I post some (final?!) comments below. Two comments first:

1. The dialogue has been going on for a long time, and the material comes from a few different sources. So the responses are more point form, and may move from point to point without a lot of regard for the previous point--there is no longer any strong unifying theme.
2. All the material below should, in my opinion, be placed firmly in the context of my VTL: What Matters? post. I feel quite strongly that those are the over-riding concerns, and that the following material is interesting primarily in terms of its' ability to determine how well the device meets the criteria described in "What Matters?"

With that said, on with the show!

Overtake The Future

On April 14, EMC will make a landmark announcement about a breakthrough approach to the virtual data center of the future.

In this virtual event, you'll get the news first-hand from senior EMC executives and have a chance to talk one-on-one with some of the EMC technologists who made this approach possible. You'll also hear from industry analysts and have in-depth background information right at your fingertips.

The event will take less than an hour of your time. It will introduce you to new capabilities that bring compelling possibilities to your enterprise, so I hope you’ll find the time to join us. 

Be sure to register at www.overtakethefuture.com.

So that is pure marketing. Normally, I wouldn't be posting this in this space, but... following the release I will have some thoughts as to the specific application to backup and recovery around some of the announced stuff. "Stuff." That is the technical term. Stuff can also be translated as "I am trying to be as vague as possible so as to not get any unwanted visits from disgruntled marketing types or any gorillas hired by them."

In the meantime it is business as usual. Normal postings will resume shortly!