« So Where Is iSCSI These Days? | Main | Informationist Musings »

January 05, 2007



Just a quick note on rip and replace with respect to Avamar. The fact that Avamar can expose the backup data as mountable filesystems allows customers to use Avamar to centralise their backups and then spool it all off to tape via their existing tape backup infrastructure.

No dead ends whatsoever.

And of course that's one of the overlooked wins with Avamar as you've pointed out, is that's real data it's showing, not a clump of data written in a file format readable only by the backup app which wrote it.

The more I see what EMC is doing with it the more I'm convinced EMC got a bargain.

Chuck Hollis

You're right -- I had forgot!

A two-step is possible, and I think more than a few people may start with that route, but -- as we both point out -- it destroys the value of the resultant backup image for reurposing exercises.

I think we got a hell of a bargain.


Great blog! I want to point two things
1. Presenting backup data in the native format is something backup vendors have played for long time. I believe it was the characteristics of the backup media which did not allow this feature to be exposed to general application (surely, it can be use to do recovery itself). These characteristics are
* Access time
* Sequential nature of the media
Now, if you use the disk as the backup media, lot of possibilities open up. One of things is the above. Only full copy will preserve the native format of the data and you could access it w/o having any additional software in the I/O path to translate the request. If you have tape format, incremental backup pieces, single instancing, you will need an additional software/protocol to expose the data in the native format.
2. Repurposing is a great idea. Read-only access does let you run some repurposing apps. But many would require write privilege to the copy. You don’t want to do that unless you have some protection for your copy!

Chuck Hollis

Hi Kumar

As far as your first observation, I would disagree a bit. As far as I can tell, traditional backup applications store objects on media (tape or disk) that are not directly usable by the application that created them, unless mediated or reconstructed by the backup application.

Snaps, clones, etc. are different, in that they are directly usable without this interpretation and/or mediation.

As far as your second comment, I don't see it as much of a problem. Many of the repurposing applications we encounter (search, workflow, compliance, knowledge management) are very happy with read-only copies of data, and -- as you point out -- that's the ideal state.

For those repurposing apps that require a (separate) writeable copy of information, existing file system snaps should be sufficient, and readily integratable with a data dedupe file system.

Thanks for the comment, and thanks for reading!


Sounds like an EMC/Avamar pitch to me. With Avamar/EMC you must REPLACE your backup software. With other solutions such as Datadomain, you do not. The less disruptive solutions are the ones that don't require a full rip and replace of backup software. All deduplication is not equal also. The trick is not really in the deduplication it is in doing it with reasonable speed. I suggest you do some homework on Avamar vs others such as Datadomain.

Chuck Hollis

Hello "Blogger182" -- what a clever name for a Data Domain employee ...

So, yes, with all client-side data dedupe, you have to replace your backup client.

That's part of the deal.

However, I believe that client-side dedupe (such as Avamar) vs. target-side dedupde offers a few significant advantages (as shown by our internal testing of products such as Data Domain's).

1. Backup windows are much shorter -- you're only sending the changed bits across the network, rather than everything as with target-side dedupe. This can be pretty dramatic in many environments -- minutes instead of hours. We've put both approaches head-to-head, and it's not a fair contest.

2. Network traffic is far, far less -- for the same reason. Again, not a fair contest.

3. Compression rates are seriously improved for client-side dedupe, as comparisons are done against all data ever seen in the environment, rather than just what's in the latest backup stream.

4. And finally, the backed up information is stored in a native file format, which means it can potentially be used for other purposes (search, compliance, archiving, etc.) rather than locked away in an unusable tape blob on disk.

That being said, I think both approaches will find their homes in the market.

There will always be people who don't want to do heavy lifting (such as replacing their backup client), and are willing to give something up in the process, and they will find target-side dedupe products (like Data Domain's and others) more to their liking.

And, yes, I did my homework. Thanks.

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!