The Backup Blog

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.

VMware Backup with Avamar and vSphere Part 2

On the previous post I had a chance to review the major backup and recovery options for VMware. I put the discussion in terms of Avamar, but a lot of that is just for convenience. If you want, you can substitute your favorite backup application in place of Avamar, and you will get more or less the same result (minus the deduplication), albeit perhaps with greater operational pain and expense.

In any event, now that I have covered off the mechanics of the three major options, it is time to take a look at the why and the how of it all. Why would I want to choose one option over the other? How do we differentiate between them? Simply put: what is the best way to back up VMware?

I am going to start by breaking one of the cardinal rules of rhetoric. I am going to state my conclusion before my premises. And my conclusion is this:

Everybody that runs transactional applications in a VM should do guest level backup. You may also do image level backup as an additional method of data protection, but guest level backup is necessary. If you are protecting anything other than a transactional application with a Windows guest OS, then an image level backup (generated by vSphere 4.0 and Avamar 5.0) is sufficient. If you are protecting a Linux guest OS machine that is not running a transactional application, then you will likely find that guest level backups are sufficient.

Now why would I insist that guest level backup is the preferred methodology if you are running a transactional application within your guest OS?

Data Protection Advisor 5.5

EMC is releasing the latest version of Data Protection Advisor (DPA) today, version 5.5

DPA has been with EMC for a while now, and it is one of those quiet little overachievers that probably doesn't get the recognition it deserves. One big reason for that is the chronic perception of backup as the most unwanted, and unloved, discipline in the IT organization. And it can be hard enough for backup folks to get funding for infrastructure and software, never mind a piece of software that is (in some senses) secondary to the whole process: software that monitors and reports on backup.

For better or worse however, this stuff is important. Simply put, the native reporting capabilities of most backup applications is not good.

As a result, most backup admins--and their organizations--benefit a lot from software that helps them monitor, report, trouble shoot, do trend analysis and so on. What is maybe not clear is just how much this stuff can help: we have found that it is often the case that DPA is so helpful that it pays for itself in a year or less. DPA can save so much administrative time and effort that it cost justifiable in a very short time frame.

Do You Need Backup?

Do you need backup?

And yes that is a serious question. (Given the name of this blog, and my chosen specialization for the last 20 years, it is understandable if you think I was asking it in jest!)

A recent real world situation makes me wonder. It also makes me wonder at what point something becomes a self-evident truth? And are we adequately equipped to answer this question with a logical and defensible answer based on data rather than opinion? Hmmm...

First, a story. One of my favourites in years of IT. And it really happened, about 12 or so years ago.

A certain organization had a badly aging mainframe. It was creaking badly (in the metaphorical sense). The maintenance cost way more than the lease on a newer system. It was bigger than a newer system--taking up too much space. It wouldn't run the most current operating system. And so on. And the only one that noticed was the lead sys admin. When he pointed this out to management--who were apparently surprised by this state of affairs--he asked for funding for a new system. His manager asked him to justify the funding request. The sys admin left, and came in early the next morning to drop off a one page business case for the upgrade. Actually, it was just three words (in 72 point text): "Think about it."

Avamar v5.0

Today EMC formally announced the availability of Avamar 5.0, which is loaded with new features and functionality. I am going to briefly review some of them here, focusing on the changes that I think will be most significant from a customer's point of view.

Having said that, please don't hesitate to ask questions or post feedback in the comments section if any of you are interested in any clarification on the material.

So what is new?

The big news is: bigger nodes, best server side task scheduling, more efficient checkpoints, new clients, desktop and laptop support, major performance enhancements for a variety of clients, and enhanced support for VMware environments.

That is the high level. Let's dive into these in a little more detail.

Copies and Backups Revisited

Mark (aka Storagezilla) Twomey wrote in his blog last week about copies and backups, and concluded that point in time copies are backups.

Hrmm. As I have said before, I am not sure that I agree with this.

I have discussed the issue here with W. Curtis Preston too, and I think there is a disconnect happening somewhere. I am fundamentally uneasy with the idea of calling a copy a backup. It seems to me that a copy is a necessary part of a backup, but not sufficient.

Would a tar ball be a backup? A gzip?

Again, I think the answer is, at best, "sort of".

And why do I differentiate between a copy and the tar ball?

Because I think there is not only a difference between copies and backups, but I think there is a difference between a backup and a backup and recovery system.

So lets start with fundamentals.

Welcome Aboard Data Domain

As of this morning, it is official, EMC has acquired a majority intrest in Data Domain, and from here forward they will be run as an product division within EMC, with the DD structure remaining intact, and Frank Slootman will head the new division.

So first things first: welcome aboard to all Data Domain employees and customers. As I have said here previously, I think EMC is a great place to work, and I believe that you will all find that to be the case too. To Data Domain customers--I think you will find EMC has a lot to offer, that we really care about our customers, and that we have a lot to talk about.

Having said that, I think most people will have two big questions for EMC: 1) How do DD and Avamar fit together? And why do you guys now have two different deduplication technologies? 2) How is DD going to fit within a unified product line?

The answers here I will give are my personal answers. This shouldn't be mistaken for some sort of official EMC statement, or any sort of look into our product roadmap! Having said that...

In answers to the first question(s): my firm belief is that source deduplication (Avamar) and target deduplication (Data Domain) are entirely complementary. Complementary in both a business sense, and a technology sense.

The Cost of Backup: Soft and Hard Costs

Continuing a theme from the previous post, I want to briefly discuss the notion of hard and soft costs in a business case or Total Cost of Ownership (TCO) study.

Hard costs are those costs associated with hardware, software, maintenance, operational expenses, capital costs, and so on. They are specific and identifiable costs to the business. Soft costs, on the other hand, are not so easy. They are often highly variable, based on intangibles, or things that are very difficult to quantify. They include things like the cost of downtime, the value of data, the benefit of higher availability, and sometimes, people and labor costs.

(Although, as an aside, I would note that people/labor costs can sometimes be soft costs, and sometimes be hard costs. If we are talking about the cost of personnel to administrate a backup system, this is a hard cost. If we are talking about lost productivity due to system/data unavailability, this is a soft cost.)

Generally speaking, most businesses will accept the distinction, and will accept hard costs and savings in a business case. It is pretty tough to argue that a tape library with tape drives carries a real and quantifiable cost: a cost of acquisition, and a cost of maintenance.

On the other hand, some businesses will accept soft costs, but many will not. Do you really save $1,200,000 if your mission critical server can be restored 4 hours faster than with a competitive solution? Do you really lose $10,000,000 if you lose (and cannot restore) 200 MB of data? Maybe. It probably depends on your industry. A financial institution may lose more, and have a better understanding of the magnitude of those losses, than some other businesses. Other businesses may not lose anything except people time. And, for better or worse, people time may not be valued with a specific dollar amount. So, for many, a business case based (solely) on soft costs is a much tougher sell.

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.

A Data Protection Taxonomy

Building on the notion of a revised data protection and backup methodology described in my previous post, I think there is another important notion here: that of a data protection taxonomy.

As we think about moving backup away from a host-centric application, to a data-centric service, I think we need a way to consistently describe the data protection characteristics of a data set. This description needs to be completely independent of any storage array, application, data type, vendor, target, or network.

We need a simple, consistent means of sharing an entire data protection policy between any device or application responsible for providing data protection services.

I could then associate the data protection policy with a data set and any service provider for data protection could interpret it, and provide the mandated service level.

Basically, any data object could have such a policy associated with it. And I could bind that policy to it in all kinds of interesting places.

How about binding a policy to a VM and making it available through the APIs on ESX or VSphere? How about binding a policy to a database and making it available through the Oracle APIs? How about binding a policy to an OS? Better yet, how about binding it to a consistency group or LUN on an array?

At this point, with the appropriate credentials, any data protection service provider--be it archival services, Continuous Data Protection (CDP) services, backup services (hosted on an appliance, an array, in a traditional backup application)--can read or request the policy, and provide the required data protection service.

More practically: any service provider, from any vendor can act upon any data set, resident upon any storage.

How is that for no more vendor lock in?