« DeDup Ratios and Fixing Backup | Main | NetApp NearStore VTL: Now Guaranteed to Cause Data Loss!? »

October 21, 2008

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Joe Matuscak

It seems to me that this is all reasons for the dedupe functionality to be integrated in the backup application (ala Avamar) rather than in third party hardware box.

Scott Waterhouse

Certainly it is. Since I am a big fan of Avamar, I find it tough to disagree with the comment. However, I think that to generalize, Avamar can do this because it has a radically different architecture than other backup applications. I can't think of any other backup application that could "just add dedup" and be expected to scale like Avamar does. TSM will be the next big test for that theory, so we shall see...

tim burlowski

Now I feel obligated to respond.

You can say "we like OST because it gives us control" all you want, it doesn't hurt my feelings. Having the backup software know a little more about the bits it wrote makes me sleep better at night.

I'll tell you that the originators of the OST idea were passionate about treating disk like disk ) - not about control or marketing.

I have to say the items on your wish list look pretty familiar to me. Not only items we hear from customers but internal work and/or discussion. Cross domain replication is do-able and make for a some great DR scenarios.

W. Curtis Preston

First, I agree with you that it’s important to be able to easily use the replicated copy of disk backup – and that currently using them is nothing short of difficult. I have worked on a few kludges that I’ll share with you. (Then I’d like to talk about Netbackup’s OSO, as our opinions couldn’t be more different.)

My first kludge is a modification to yours. Instead of copying one set of virtual tapes to another set, I’d suggest using the inline tape copy functionality of NetBackup, CommVault, and Backup Express. My experience has been that it slows down the incoming backup by 10-15%, but when you’re done, you’ve got two copies. Then you can replicate one and not the other. It’s the same as your idea, but using inline tape copy instead of a regular copy. (And, remember since it’s deduped, two copies takes up the same space as one copy.)

Second, there’s another kludge that I use if we’re talking NFS/CIFS-based systems such as Data Domain, Quantum, NEC, or EMC. There’s usually no problem with having another media server copying backups from the same disk, right? (Such as two systems backing up to a single NFS mount point.) So, let’s make the media server that’s backing up to NFS mount A and the media server that’s going to copy backups from NFS mount B (which is a replicated copy of NFS mount A) THINK they’re accessing the same system. All you do is mount them as the same name (with some backup software you may need to fake out the local hosts file if the software actually notices the NFS server name), and the media server accessing the replicated backup thinks its accessing the same backups that the original media server wrote. The only problem here is that you can’t start the copy until the replication is finished. So you “just” need a script to coordinate that.

Your comments about Symantec’s OSO, though, baffle me. They also contain at least two incorrect statements. The first is that “they don’t.” Maybe they don’t with EMC (your box doesn’t support OSO yet), but they DO with Data Domain and Falconstor. For target systems that support OSO, they absolutely solve the problem that you’re concerned about. The second incorrect statement is that “It does not work with virtual tape.” It can work with virtual tape; it apparently doesn’t work with YOUR virtual tape. But I know of three VTL vendors (Falconstor, IBM & SEPATON) that are programming (or have programmed) to the OSO API. The API doesn’t care how you store the backup, just that you do store it and will give it back when you’re asked for it. If you want to store that on a filesystem, great. If you want to store that on a virtual tape, knock yourself out. Just be able to restore it or copy it when NBU asks for it by name. They even allow you to use IP or Fibre Channel to transfer the data to your device. Most of the current implementations have been via IP, but soon others will have FC-based implementations.

If you use it, NBU will know about both the source and destination copies, and can use the destination copy to make other copies (like tape). Since it fixes the problem that you’re against, why are you so against it? (Surely it’s more than just that it doesn’t currently work with your product.) What are these limitations to which you refer?

As to your depiction that this was some sinister plan by Symantec for global domination, that’s just silly. Every backup app wants to control everything going on in its sphere of influence, and of course NBU wants to control the copies of its backups. It just makes sense. What they asked themselves is “if we know we’re going to disk, why should we create an interface that continues to pretend it’s tape? Why not just make an interface that says ‘here’s the backup, here’s its name, you figure out how to store it.’ That’ll allow each vendor to figure out how they want to store it.” While I initially went into it kicking and screaming, I now see the move as nothing short of brilliant. They’ve got all of you programming to it, don’t they? And I was just in a meeting with a multi-billion-dollar client whose requirements can ONLY be met by OSO.

I also blogged in more detail about this here:
http://www.backupcentral.com/content/view/198/47/

Scott Waterhouse

Curtis, thanks for the comments. Too much here to respond to in the comments. I will try to bring some of this to the top, where it deserves to be, with a fresh post early next week.

As far as the OSO/OST stuff--OK, maybe I come off too strong. I have to hand it to Symantec for at least trying to do something about the issue. (Stay tuned for what we have up our sleaves in the next few weeks--I am not sure when I can publicly disclose, but you can be sure I will post as soon as I can!)

My objections from the last time I took a close look at it:

1) disk only, not for virtual tape (last I checked... this is not obvious until you dig). Sounds like either Symantec or vendor partners have remedied this now.

2) manual browse only of target backup data (i.e. it is a DR process to access)

3) only actually implemented with DD (if you say FS now does it too then great, I hadn't heard that Sepaton or IBM were actually shipping anything yet)

4) only with their "open storage disk" license (forget the exact name) which charges by TB ingested, not stored. This alone will pretty much kill it, I have been having customers telling me that it is up to 5x more expensive than "traditional" Symantec licensing.

5) is driven by NBU, cannot be informed by appliance of a replication.

6) cannot cross master server ownership (yet--this is on roadmap for 6.5.3 I think... but we shall see)

W. Curtis Preston

As to what you have up your sleeves, you should tell your marketing folks to brief me. I can't talk about what I don't know about.

1. It never was disk (filesystem) only. The spec doesn't specify how the data is written. It's just that it was easier for the filesystem guys, as they already knew how to store a file without putting it on a tape. The VT guys have to do more work.
2. That's news to me and I'll have to look into that.
3. Yes, DD and FS have done it and others will follow. But saying "they only do it with DD" in the dedupe space is like saying "they only support symmetrix." They kind of own the space, eh?
4. Their disk license pricing has changed. It's priced like Avamar now (by the upfront TB).
5. Yes, it's driven by NBU. That's the whole point. Maybe they'll add what you're asking for later. But right now, nobody that replicates can replicate to a different barcode and/or filename, so they'd have a feature that doesn't do anything if they did it today.
6. Yup.

Brad Jensen

Wow, reading about the problems of VTL technology is like reading about buggy whips and horseshoes.

"I can't keep this dang torch lit!"

The comments to this entry are closed.

Search The Backup Blog

  • Search

    WWW
    thebackupblog