Networker

Re: [Networker] new to Virtual Tape Library - what are the benefits?

2007-08-23 07:49:49
Subject: Re: [Networker] new to Virtual Tape Library - what are the benefits?
From: "Kantor, Adam" <adam.kantor AT BASSETT DOT ORG>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 23 Aug 2007 07:43:06 -0400
The one thing that has to be remembered is that Networker does not
comprehend a VTL as anything other than another tape library.
Therefore, you most cetainly can multistream data to a VTL device, you
can change (and have an affect) the number of target sessions for a VTL
device.  The bottom line:  whatever you can do to a 'real' tapedrive,
you can do to a VTL tapedrive.  It's a tough concept to wrap your arms
around, but if you come to grips with it now, then it will help in the
future. 

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of mark wragge
Sent: Thursday, August 23, 2007 6:58 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] new to Virtual Tape Library - what are the
benefits?

This has been a great thread with excellent feedback. 
   
  One thing i am still unsure of is if it is possible to multistream to
a virtual tape device. Is the target sessions setting on the virtual
tape device relevant and will it accept more than one stream at a time?
  

Curtis Preston <cpreston AT GLASSHOUSE DOT COM> wrote:
  I've read this whole thread now and wanted to comment on it with a
little more thought...

I in favor of VTLs or other intelligent disk targets (IDTs). It's not
necessarily whether or not it's pretending to be tape; it's whether or
not it deals with the issues of using "regular" disk, which are:

1. Difficult to share between multiple storage nodes - must partition

2. When partitioning for multiple SNs, you have to decide how big to
make each slice.

3. 1:1 relationship between size of backups and size of disk (i.e. no
compression or de-dupe)

4. Fragmentation: users have reported issues with using filesystems as
targets for extended periods of time unless they're clearing the
filesystem every night.

IDTs remove with these issues:
1. Easy to share - with a VTL, use DDS in NW or just make multiple VTLs.
With a NAS IDT (Data Domain, NEC Hydrastor), just point a share at it.

2. Do not have to partition by storage node or even NetWorker server.
Whatever storage a SN uses, it uses.

3. Some have hardware compression and others have de-dupe. I've seen it;
it's real. And my opinion is that as long as you're also copying
everything to tape, I've got no issues with using de-dupe at this stage.

4. Fragmentation does not seem to be an issue as they use a MUCH larger
block size that's better suited to backups. Fragmentation issues have
also not been reported.

Issues:

1. There is the issue with managing migration to tape. With NetWorker,
there are easy ways and hard ways.

With disk/AFTD, you would use the disk staging facility in NW. It will
automatically stage backups to tape from disk, and delete de-staged
backups to make room for new babckups.

With an integrated VTL (like the EMC CDL, IBM, Sun, Falconstor, NetApp,
et al), you can have the CDL manage the migration. It sits between your
networker server and the physical tape library (PTL). It inventories the
PTL and represents to the NW server virtual tapes with the same barcode
and capacity as the real tapes. You back up to the fake tapes and eject
them. It then automatically copies them to physical tape.

If you don't like either of these options, the "hard way" is to script
your way into happiness. If you like this method, there's not much
difference between an AFTD and a VTL/IDT from a migration perspective.

2. There's also the issue where you can't expire a tape until all its
backups expire. This is no different than physical tape. I think this is
pretty easy to deal with. Either use really small virtual tapes or mark
your tapes as full with a script after each night's backups. A 400 GB
tape marked full in a VTL won't take up 400 GB, so that's OK. That way,
each night's backups are on their own set of tapes, causing all of them
to be expired when those backups expire. (You also need to segregate by
retention period if this is to work well -- just like with real tape.)
You don't have this issue with an AFTD as it can expire individual
savesets, but I think that an AFTD comes with too many other problems in
large NW environments.

3. If you use an integrated VTL, there is the issue of matching virtual
to physical size. The big thing is that virtual tape MUST fit on the
physical tape. Some VTLs allow you to pick the point at which the
virtual tape is full. If you pick a size that's too big, you won't fit
onto the physical tape and you've got badness. I like the new feature of
"right sizing," where the VTL figures out when to stop by sampling the
data that's coming through and seeing how well it's compressing.

4. The license issue. As long as EMC makes it an option, it's not a new
license they're trying to force down your throat. It's an optional
license that allows you to configure your VTL any way you want (e.g.
number of slots, etc.). As long as you stick with the "real" license,
you're limited to what you paid for. Don't forget that AFTD costs money,
too!

I hope this helps.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

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


 Send instant messages to your online friends
http://uk.messenger.yahoo.com 

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


NOTICE OF CONFIDENTIALITY
This electronic message, including attachments, is for the sole use of the
named recipient and may contain confidential or privileged information 
protected by New York State, and Federal regulations. Any unauthorized 
review, use, disclosure, copying or distribution is strictly prohibited. 
If you are not the intended recipient or have received this communication 
in error please contact the sender or email.security AT bassett DOT org and 
destroy all copies of the original message. Thank you.

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

<Prev in Thread] Current Thread [Next in Thread>