The Backup Blog

Data Protection Advisor

Note: 2nd of 3 updates on new product announcements for this week. The 3rd installment will cover what is new with NetWorker 7.5.

I thought I would take the opportunity in the second of my product update discussion to discuss one of the lesser know, but most relevant and useful products in the lineup: Data Protection Advisor (formerly known as EMC Backup Advisor, and prior to that as WysDM). Data Protection Advisor, or DPA, fills a big gap for most backup and recovery administrators: the reporting, diagnostics, and analysis of their environment in a useful way.

Notice that I say useful: having 400 canned "reports" does nobody any good if the reports are not useful and relevant.

Avamar Updates for v4.1

Note: This is one of 3 posts I have for this week which describe in more detail some of the more interesting components of EMC's November 18th backup, recovery and archive announcements. The next two will deal with DPA (Data Protection Advisor) and NetWorker.

I had previously written about the benefits of Avamar for VMware environments and how Avamar is basically free when deployed for VMware. The growth rate for Avamar has been staggering: source deduplication is uniquely powerful in some use cases. There are definitely occasions when the flexibility and scalability of Avamar source deduplication significantly differentiate this approach from target deduplication solutions. Any time you care about bandwidth between the backup client and the server (such as remote office backup), and any time you are in a position to seriously consider downsizing the role of tape, Avamar should be something that you evaluate.

Free Avamar for VMware

I thought I would return to the subject of Avamar for a quick discussion of one of my favorite pieces of backup software. The geek in me loves new technology and new gadgets, and the contrarian in me loves the thought of doing things different--so long as different is also better.

Avamar meets both of those criteria.

I have written about Avamar for VMware before, and how it is such a good thing. And six months after writing that, it is still a good thing. It doesn't matter if you opt to deploy it in a guest VM, or along side VCB proxy backup, it makes backup of a VMware environment vastly better than it is with traditional backup.

So call it an unintended consequence, but there is something else that happens when you elect to back up an ESX server with Avamar. That is, something else in addition to a reduction in the stress levels of backup administration roughly equivalent to a 6 month stay on Bora Bora, a reduction in storage requirements equal to a mountain of tape, and a reduction in bandwidth requirements of equally gargantuan proportions.

DL3D: The Benefits of Immediate Deduplication

One of the most powerful features of the EMC DL3D is its ability to do both in-line and post-process deduplication. It is one of the few (the only?) deduplication appliance that offers users this flexibility, and in fact lets you do both on one appliance, depending on the requirements of the data being backed up.

Certain competitors have done their best to portray this flexibility as a weakness. Huh? Since when is choice a bad thing?

Well, it isn't a bad thing at all. Choice is good. Flexibility is good.

The other criticism that gets leveled against the DL3D here is that the in-line is not really in-line. In particular, Data Domain attempts to claim that EMC doesn't do in-line deduplication at all--that we write to a disk cache, and that this lets us be deceptive with our performance numbers.

Nothing could be more misleading.

NearStore VTL: Requiem for a Dream

In a recent posting, Curtis Preston wrote some pretty insightful words. I was waiting for the appropriate moment to reference them, and this seems as good as any. Since Val Bercovici referenced them recently, it seems doubly appropriate. Curtis wrote:

I treat vendor blogs as a printed version of a sales rep talking to me. I expect the sales rep to tell me all the best things about their product and none of the bad.  I expect them to try to bash the competition at some point (although I don't like it when they do), but I also believe that the best source about their competition isn't them; it's their competition. So when they tell me that the other vendor's blood is green, I don't believe them.  I grab the nearest sales rep and prick them with a needle and look very closely.

My thoughts on this? This is all true, with one important exception: where a product has a specific and significant shortcoming. To (unfairly?) perpetuate a stereotype of sales reps, we wouldn't expect that rep to immediately admit, or even admit under anything less than extreme duress, a critical failing of a product, would we? So, after thinking a lot about this, I think there is a valuable role for the competitive blog post: to expose a critical short coming. Hopefully this can be accomplished without any unnecessary histrionics, vaudevillian showmanship, or needless hyperbole. I regard this as similar to the role of the press in a democracy, or the role of the opposition in government: to provide checks and balances, and a contrary opinion. To keep everybody honest.

In the blogosphere, we have the added luxury that this can be a dialogue. If a competitor disagrees, there is every opportunity to engage in conversation, and point out the failings of the post. Does the reasoning hold up or does it not? Is it sound and relevant, or is it much ado about nothing? And ultimately I hope the readers bring their critical reading skills to the table so they can judge each position on its own merit.

So, when I posted that the NearStore VTL was practically guaranteed to lose data, I hoped that the analysis would: a) stand up to scrutiny by NetApp, b) that they would engage in dialogue if, in their opinion, I was wrong, and that, c) it was relevent. Well, like Meatloaf said, 2 out of 3 ain't bad.

Deduplication and Replication Revisited

After my post two weeks ago, I wanted to come back to this topic and revisit some of the issues, largely thanks to a couple of very insightful comments from Curtis Preston. He raised some good suggestions with respect to replicating deduplicated data sets.

A brief recap of my prior post is this: how do you get the backup application to recognize the deduplicated data set at both the source and the target in such a way that you can use the data at both sites (for recoveries, data portability, data refreshes, etc.)? It isn't easy! I pointed out a couple of work-arounds, and Curtis added two. Because I think they are important, I am going to quote Curtis wholesale here.