« NetApp NearStore VTL: Now Guaranteed to Cause Data Loss!? | Main | NearStore VTL: Requiem for a Dream »

November 04, 2008

Comments

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

W. Curtis Preston

Hey, look pal. ;) If you’re going to use my name, at least put the “W.” in there. It’s all about the brand, baby! Don’t make me start calling you “Cott.”

Just a few thoughts:

“both incoming copies count toward the total available deduplication bandwidth”

That’s a very good point that I hadn’t thought about, but the original idea also takes up bandwidth, although not dedupe bandwidth in your architecture. (The read operation required by the copy would create I/O, but in your architecture it would typically be doing a read from an original, non-truncated copy. But it’s I/O nonetheless.

“this is a really good example of why the backup application needs to relinquish some control to the appliance”

Agreed, which is why I was so hard on you for being so hard on Symantec, the first backup software ISV to do something like that.

“There is something about having two devices on the same network with with the same name--and having each device accessed by a common application--with only a tricked out local hosts file to prevent potential issues around open files and locking.”

You’re absolutely right. It’s like democracy. It’s the worst form of government, but it beats all the rest. (I forgot who said that first; it definitely wasn’t me.)

“TSM does not support the notion of twinned writes”

I actually believe they do, but very few people use it. One of the biggest concerns of TSM users during backups is the number of mount requests they’ll get for tape drives, using tape twinning would actually exacerbate that problem.

One other possible solution to the problem is to replicate all backups from a device connected to backup server A to a device connected to backup server B, and have backup server B inventory and scan the contents of the tapes as they show up on the other side. Not only is this possible, it’s actually been automated and is now shipping in a supported solution from Overland. It currently supports only Backup Exec, but the architecture will support any products that allow you to scan the contents of their tapes. This is just about any product except for TSM tapes. You cannot scan their contents in with TSM like you can with other backup products. No catalog, no restore.

“One possible solution that appeals to me here is running your backup master within a VM. This works for NetWorker, and it works for NetBackup (it is one of several solutions according to them)”

I don’t know know who you’re talking to at Symantec, but that is an unsupported option. I’ve done it. It totally “works,” but performance is abysmal. I’ve actually VM’d a lot of backup servers for testing purposes, and my experience has been the same regardless of which backup software we’re talking about.

Ernie Denzer

So, the problem is not the dedupe and replication appliance but the interface to the Backup Software. Why not test CommVault? First configure the Dedupe appliance as a NAS or CIFS Share and NOT as a VTL. To do a restore from the appliance at the DR site (or from tape) just change the restore source to 2 or 3. In case of a DR (or just power off the BUR server and appliance at the source site to test) CommVault automatically goes to the DR site appliance. Good Luck,

The comments to this entry are closed.

Search The Backup Blog

  • Search

    WWW
    thebackupblog