Having had a brush with VTLs over the summer I have a couple of comments
on the thread.
The virtual tape size and physical tape size is a real issue, the VTL
(at least the one I was playing with) had no way of getting out of this
so we had to use nsrstage to the same pool after adjusting the max size.
Virtual tapes can get corrupt (for one reason or another). Once again,
the VTL didn't come with any tools like we have with Networker (we can
use nsrck to fix various problems with client index but there is no
equivalent consistency checker for virtual volumes). Same thing with the
metadata (which should be a straight forward job to recreate). (nsrstage
to the rescue again...)
It is possible to get volume and barcode mismatch on Networker but the
VTL reports both the same (makes sense if you can grasp the idea that
the VTL is just a tape library to Networker) - as an aside this was
caused by drive mapping changes on a Windows box (rearranged the order
of the drives and so Networker loaded a tape in one drive and labelled
it with the barcode from another. VTL being blissfully unaware of this
exported the tape to a physical tape. Restore calls for tape (by volume)
VTL doesn't recognise it - have to manually load the barcode that
Networker has for that volume in order for it to work (nsrstage to the
rescue again...)
They do appear to be pretty versatile (the ability to replicate from VTL
to VTL makes offsiting data a breeze) but the supporting software
utilities have a way to go yet.
And, as with anything that uses disk, when estimating how much you'll
need, double your estimate (and then add some more). You'll need it.
Personally, I prefer the AFTD approach (been working well for us for
years - once you get round the idea that Networker will not straddle
devices so you need to make sure a saveset will fit). Oh yes, and the
multiple reads are a bonus that I didn't see with the VTL.
Regards
Bob
>-----Original Message-----
>From: EMC NetWorker discussion
>[mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Kantor, Adam
>Sent: 23 August 2007 12:43
>To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>Subject: Re: [Networker] new to Virtual Tape Library - what
>are the benefits?
>
>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
>
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
|
