« Why Cisco's OTV Matters For The Private Cloud | Main | 10 Cloud Secrets For IT Service Providers »

February 09, 2010


W. Curtis Preston

It wasn't one of your competitors that started this discussion, Chuck, it was me on my blog:

And I wasn't pushing a competitor's snaps & replication; I was pushing the concept that the two together can be an effective backup and recovery system -- one that is never "backed up" in the traditional form.

Now let's talk about what you wrote.

"Whether we call these snaps, clones, remote replicas, continuous data protection, or even the underlying dedupe capabilities of DataDomain and Avamar – you can see that line of thinking across our portfolio.

So far, we're all in agreement."

I can understand your confusion if you got your information second hand, but I wasn't just talking about backup to disk here. I was specifically talking about snapshots & replication. That does not include Data Domain and Avamar. While both are fine products, they both still think of backups in the traditional sense. That is, that the "backup" needs to be in a different format than the original. The whole point of my post was that I no longer think this is necessary.

Not Everyone Is Up For Process Change

I totally agree with that. I made the post only for those that are considering mass changes to their backup system. I'm saying, "as long as you are going to spend a bunch of money, perhaps you could consider this completely different way." It's what I do.

Orchestration Matters

I couldn't agree more. All these snapshots have to be configured, managed, reported on, etc. I touched on that in my blog.

The Continuum Matters

Not sure I understood the point you were trying to make here. Of course you should consider BC, DR, and archive when making such decisions. But I'm not sure what that has to do with whether or not using snapshots & replication as your backup system is a good idea.

Choices Matter

You said that "the general thinking here is a preference for solutions that are loosely-coupled with storage arrays, rather than ones that are tightly coupled."

I do think that is the Convential Wisdom, but I'm revisiting that idea. I'm wondering if perhaps a tightly coupled backup and recovery story would actually have the most value and cost the least to operate. For example, the whole point of dedupe goes away if you're not making duplicate copies of your data.

BTW, I'm really surprised it's a point that you're making. Many of the data protection options from EMC are very tightly coupled with your storage.

You also talked about "the more obvious need to put your recovery copies on something other than the physical device where the primary copies live"

Well, of course, and I addressed that in the blog. That's why I didn't just say snaps. I said snaps and replication.

Chuck Hollis

Curtis -- I think there's much that we agree on.

As far as your "all in one" vs. "specialized for role" discussion, I think we'll see one preferred for smaller environments, and more specialized kit for larger ones.

Thanks for the thoughtful comment ...

-- Chuck

Gene Piatigorski


Awhile back I posted a reply to you that suggested that performing backup operations that pull the data from primary storage to the backup server to be stored on some other storage media is the legacy process I for one would LOVE to avoid. Appologies to Curtis, but I think this is an obsolete view (with de-dupe or without) of the best practices for backup. It is one that we are stuck with, because 'the we have always done it this way' mentality is preventing us from doing something better.

Why can't my primary storage container have the built in version control for data that it is receiving from the application hosts and have the intelligence to retain the exact number of copies for the exact amount of time that a user would provide via a policy? I think your customers will break down the doors to your sales staff office(s) to get this capability.

Chuck Hollis

Hi Gene

The inconvenient truth is that storing recovery copies (of any sort) on the primary storage device increases risk of data loss to unacceptable levels for many use cases.

Hardware fails, software fails, people fail, data centers fail, etc. Distance is good, more distance is better.

As far as your thoughts around "exact number of copies", etc. what you're describing is pretty close to today's CDP. Are you thinking of something different?

-- Chuck

Joerg Hallbauer


I think you are confusing BC with DR, and after you posted such a great explanation of the continuum from BC to DR in your original post. Daily backups don't necessarily need to go to a completely separate device. these backups are mainly used for recovery of accidental deletions, corrupt data, etc. Those backups can live on the same device in the form of snaps, clones, etc. just fine. If you also then implement DR, and replicate that data to another site, you are now protected against the issues you describe around array software, hardware, and process/people failure as well as site failure. This leads to some discussion about what a "disaster" really is. Most storage vendors like to use the "smoking hole where your data center used to be" scenario to describe a disaster. But disasters come in much smaller packages. I've had entire arrays go down due to both hardware (disk) problems, as well as software/firmware issues. That's a disaster, and precipitated a failover to the alternate site for all of the applications using those arrays.

the bottom line is that for BC, or standard backups, snaps works just fine. For a disaster, some form of replication is going to be necessary no matter how you implement the DR plan.


Chuck Hollis


You're right, I should have been more precise, and -- most of all -- I of all people should know better!

Thanks for the clarification.

-- Chuck


A lot of business that I have been working with lately are looking for off site incremental solutions that support file versioning. They no longer want to spend hours sorting through tapes/hard drives looking through compressed folders for the right file(s).

As to your comment on "Not everyone is up for process change"... I can't agree with you more! This is especially true in large fortune 500 companies as even the slightest change in process can cost millions just in communication efforts to inform employees and to establish new documentation

Chuck Hollis

Not to offer the shameless product plug, but there's been good takeup from many individual business users of the MozyPro offering for just that reason.

I've been running it for over a year now, and -- occasionally -- I need to get a versioned file back. It works as advertised for what it was intended to do.

Thanks for the comment --

-- Chuck

The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!