The Backup Blog

More Thoughts on TSM

I thought I would wrap up my thoughts on TSM, for now, by talking briefly about two things TSM users are typically concerned about: migrating TSM clients and getting off TSM.

The first one of these is something we talked about just recently. And I think I covered off the easiest way to move to a Data Domain target with TSM from a tape or virtual tape target. But one of the things I frequently get asked about is: what about clients backing up using client side compression?

This practice seems to be relatively common amongst TSM users—I could speculate why, but I won't. Suffice it to say that it is far more common in TSM environments than it is for users of other backup applications. And it is a pernicious practice that is just not good. In any way. Sure it saves bandwidth. Sort of. But bandwidth is free, more or less. And it isn't a big enough deal to enable remote backup, so really it just saves local bandwidth. Which is even closer to free.

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.

Inside Avamar: Fast Backup and Finding Backup Candidates

Last time out, we talked about Avamar's global client deduplication. This time, I want to go into some more depth on what makes Avamar so fast for some types of backups.
 
Saying something is "fast" is always a bit subjective. I know that some things like Lamborghinis are fast. I know that Valentino Rossi is fast. But how fast is Avamar?
 
On average, Avamar is about 90% faster than most other backup products to make a backup of an unstructured data set. And in backup, speed matters. In fact, I would argue that it is the most important thing a backup application or platform can offer. So finding a solution that lets you cut backup times by 90% is important. And in some cases, it is crucial. For platforms and infrastructure that have expreienced 24+ hour backup windows, this is a decisive factor.
 
How does Avamar do it? Well, Avamar has a pretty elegant way to reduce the amount of time that it takes to determine what needs to be backed up.

Inside Avamar: Global Client Deduplication

I spend a lot of time talking to people about Avamar. I think it is a great application that pretty radically reinvents backup architectures. It does so many things well, and has consistently been ahead of the curve in terms of delivering advanced backup technologies. For example, Avamar was one of the first to market with a true disk based deduplication solution for backup.
 
And often I tell people that Avamar's overt association with deduplication is one of its' challenges too—in the sense that Avamar actually does two things at the client level that are really important. It is not just deduplication, but the duration and resource utilization of the Avamar client that are so impressive. Not only does deduplication reduce the amount of data to be backed up by 99% or more in many cases, but the duration of an Avamar backup is usually 90% less than the duration of a standard backup. To those of us that are concerned about growing amount of data and the impact on backup windows, this is a fundamentally important characteristic, and one that is, in my opinion, just as important as deduplication itself. (And one that I will discuss in a follow up post.)

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.

The Growing Digital Universe: What It Means For Backup

Over the last little while, we have become used to seeing discussions of data and storage for Big Data. As if Big Data possesses a unique set of challenges around the acquisition, management, replication, and protection of the data. And so it does.

For now.

Because after reviewing the latest set of statistics from the 2011 Digital Universe study it is clear that the challenges (or "opportunities" as Chuck put it on a recent call) faced by Big Data users today are going to be the same challenges that most enterprise IT shops are going to have face in the years to come.

EMC Avamar v6.0

Today EMC is announcing a new version of EMC Avamar software and hardware. With the latest release come a ton of new features, bigger, better, faster hardware, and support for integrating Avamar with Data Domain.

So, without further preamble, let's jump into what is new in Avamar v6.0:

On the hardware side, the new release offers higherdensity nodes with greater performance. Nodes are now offered in 4 different capacities: 1.3 TB, 2.6 TB, 3.9 TB, and 7.8 TB. The standard Utility and Accelerator nodes continue to be available and serve the same function in Avamar v6.0 as they did in previous releases. What is more, is the performance of the node relative to important internal system maintenance and upkeep scales with capacity. The 7.8 TB node offers twice the performance of the 3.9 TB node. For some important tasks like garbage collection and file system checks this means there is no longer any good reason not to use the highest density nodes even for data with exceptionally high change rates.

Variable Block and Fixed Block Deduplication

I saw this little quote on Techtarget today: "File-level deduplication will save a relatively small amount of space on your disk/tape archive. Block-level deduplication will save more space on your disk/tape archive, and variable block-level deduplication will save even more space on your disk/tape archive." For those of you interested in reading the whole article, it can be found here (registration required).

While the statement is true, it is a little light on detail, and downplays the importance and impact of the different technology choices. By way of setting expectation, we could expect the following deduplication ratios when backing up the same data set with the same retention ratios:

• File level deduplication: 3:1 to 5:1
• Fixed block level deduplication: 5:1 to 10:1
• Variable block level deduplication: 30:1 or better

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?

VMware Backup with Avamar and vSphere

Edit: I am taking the unusual step of adding this after the original post was finished. As of the moment, it may be best to regard the conclusions in the post as tentative only. The post has generated a flurry of questions and controversy, with several people saying that I am wrong. Unfortunately, nobody has been able to provide a piece of definitive technical documentation (a white paper, or a support document, or relevant piece of text from an administration guide) that clearly describes the issue. Let me be clear: I am OK with being wrong. I kind of hope that I am--it would be just fantastic if we could get image level application consistent backups. But it is not OK that the answer to such an important issue is so obscure. So at the end of the day, if I am wrong but manage to get a clear and well documented answer, that is good enough for me! S.W.

Continuing the posts here and here, I wanted to have a very quick discussion of application consistent backup. This particular issue came up as a question to the other posts--and simultaneously in a discussion with W. Curtis Preston. And the issue is this: can you get .vmdk level application consistent backups of Microsoft guests under VMware ESX 4.0 with vSphere?

So, long question! Why are we asking this? Remember I concluded that you could not get an image level, application consistent backup, that is guaranteed to be consistent--even with vSphere 4.0.

Now Mr. Preston and my smart reader rightly pointed out that VMware says you can. Thanks in advance to W. Curtis: you can find those claims here and here  on the VMware site.

So what is going on here? Was I dead wrong? Does VMware actually permit application consistent image level backups via VMware Tools and support for the MS VSS provider?