You must have misread my post (or I mistyped) it if you thought I was
advocating for bigger virtual tapes.
The red herring I was referring to was that you would get barcode
mismatches by using integrated VTLs. It just doesn't happen if you
follow any of the best practices for such configurations. (You don't
HAVE to match bar codes, but that would be stupid, IMHO. It's only FUD
thrown out by competitors that don't have the functionality.
I didn't see you making an argument of "I want to keep my virtual tapes
smaller, and so that's why I do it this way." I saw that as a
parenthetical comment, like, "Oh and BTW, I can also keep my tapes
smaller."
I was only making the point that one of the reasons you stated for not
doing it this way was a red herring.
________________________________________________________
Curtis Preston | VP Data Protection
GlassHouse Technologies, Inc.
T: +1 760 710 2004 | C: +1 760 419 5838 | F: +1 760 710 2009
cpreston AT glasshouse DOT com | www.glasshouse.com
<http://www.glasshouse.com/>
Infrastructure :: Optimized
________________________________
From: Francis Swasey [mailto:Frank.Swasey AT uvm DOT edu]
Sent: Tuesday, September 02, 2008 12:42 PM
To: Curtis Preston
Cc: EMC NetWorker discussion
Subject: Re: [Networker] Query in Staging from adv_file
Curtis,
You were the one arguing for using small virtual tapes to make
everything work really slick with the VTL. Now, you are saying doing
that is a red herring. What do you really believe?
On 9/2/08 2:42 PM, Curtis Preston wrote:
I do not want to get into the situation where the
VTL has copied a virtual tape (VT00001) out to a physical tape
(VT00001)
and then NW recycles that tape in the VTL and uses it again. NW
has
now
lost track of the data that is on the physical VT00001.
This is a red herring, IMHO. In any integrated VTL worth its salt, this
is done with barcode matching:
1. You put physical tape LT00001 into the physical library (PTL)
2. VTL inventories PTL, finds LT00001
3. VTL adds LT00001 to inventory of VTL
4. NW backs up to LT00001
5. VTL sees LT00001 is full, copies it to real LT00001
5. NW ejects LT00001 from VTL, triggering eject of real LT00001
When you're done, NW thinks it copied to LT00001, and thinks it ejected
it, and that's what happened. If you expire/recycle LT00001, there
won't be any difference from what happened if the tape was physical from
the start.
If you can keep NW from ever recycling the virtual tapes so
that it never loses track of the data on the physical tapes
then you'll be ok.
Again, this is no different than physical tape. Why would you be
expiring a tape that has backups on it you want?
Much easier (in my mind) to have NW stage the data from the
virtual
tapes to a different physical tape. Doing that means that you
can have
small virtual tapes and large physical tapes and not waste tape
media
and according to recent discussion here
It's easier IF YOU CAN DO IT. What might stop you? Two things.
First, in the VTLs I've tested, there is sometimes a significant
performance difference between the copy speed of a
backup-software-managed copy and a VTL-managed copy. (It has to do with
the makeup of the backups on the tape. If there are a lot of files in
it, or if there are a lot of small incremental images, the copy can take
a lot longer if you do it via the backup software.) I had one customer
that tested the alternative, and found it to be about 20 times faster in
his environment to have the VTL make the copies.
Second, it's not like it's easy to automate making clones in NW,
especially in large environments. If you're good at scripting, you can
make it happen. If you're not, this is still NW's Achilles' Heal. BUT,
if you want to just back up to virtual tape, have those virtual tapes
become physical tapes, and then send those physical tapes offsite, you
can do that with no scripting -- if the VTL supports copying to physical
tape.
...increase performance on the VTL
Completely disagree based on what I've seen.
...and decrease the risk of virtual tape contention.
Again, I don't see where this is an issue.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
--
Frank Swasey | http://www.uvm.edu/~fcs
Sr Systems Administrator | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
"I am not young enough to know everything." - Oscar Wilde (1854-1900)
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.
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
|
