Networker

Re: [Networker] VTL or disk cabinet backup

2007-11-07 10:40:15
Subject: Re: [Networker] VTL or disk cabinet backup
From: Yaron Zabary <yaron AT ARISTO.TAU.AC DOT IL>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 7 Nov 2007 17:29:08 +0200
Such file systems are available from several vendors, namely SGI's CXFS, Sun's QFS and Tivoly's SANergy. Although exotic, they should do the trick. When dealing with such complex backup solutions, you cannot get away with simple and cheap solutions. Keep in mind that regardless of your exact SAN topology, you are already buying an HBAs, SAN switches and some multi-terabytes storage to begin with. So the price tag for such a solution is already high and the added cost for the software, while not marginal, does make some sense (if you really need this performance).

Curtis Preston wrote:
You can't share a single LUN/filesystem with two servers unless you
share it via NAS or some really cutting edge global filesystem software.
Once you do that, the cost justification of "just using disk" goes out
the window.

And, yes, I think that storage node A being able to copy storage node
B's backups is essential in a lot of designs.  For example, consider a
storage node that's just backing up itself.  It's only got enough time
to do the backup, and does not have the time to do the copy.  Then you
have a "real" storage node do the copy.  It's also important for highly
available restores.  All "regular" storage nodes should be able to
access each other's backups.  One goes down and another can do its
restores or backup -- IF it can access the other servers' backups.  With
a VTL or dedupe NAS that's a piece of cake.  It's NOT easy with plain ol
disk.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies -----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Dag Nygren
Sent: Tuesday, November 06, 2007 11:43 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] VTL or disk cabinet backup

I would suggest that what you describe is not shared.  First, you
would
have to size each LUN appropriately for each server.  Some LUNs will
always be too big, and some LUNs will always be too small.

Not if you use the same filesystem, just different directories.

 In addition,
you can't have storage node A back up to disk slice A, then have
storage
node B clone storage node A's backups, cause it can't see them.  If
you
could, that would be sharing.

Do you really need that?

Best
Dag

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


--

-- Yaron.

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER