OK....so now I have to disagree with Curtis on his disagreement....

We tried using Vault with both preserving of Multiplexing and doing
de-multiplexing on the vault copies.  In both cases, we did not get very
good throughput.  Most of my time was spent trying to balance the amount of
space on the VTL's that had not yet been vaulted.  We also found that when
you have an image consisting of lots of small files, it will be slower than
if you have a few very large files (like database files).  

When stuff did get vaulted, we had to bpexpdate the images on the VTL's to
free up space for the ever-increasing amount of backups coming in.
Symantec/Veritas had people helping us with this issue for weeks before we
finally gave up and went with the "Direct Tape Copy" cloning method built
into the NetApp VTL's (good stuff).

We were having a terrible time with trying to get Vault to keep ahead of the
data coming in for backups to the VTL's....and that was before we had fully
migrated all of our legacy backup systems to our new environment.  We had to
have scripts to keep track of what we could bpexpdate off of the VTL to make
room for backups.

Yes, we realize that NetBackup does not really "know" about the true
location of the tapes that we clone using the Direct Tape Copy method.  And
we had to partition our physical tape library to accommodate this approach.
But this was a small price to pay for the problems we encountered using
Vault.  And, I would happily deal with this  rather than have to worry about
whether or not an older backup was successfully Vauted or not or if I have
enough space on my VTL.

Right now our monitoring of the VTL's consists of checking on available
tapes and assigning new ones when they get low.  We have a script that eject
full tapes from the VTL's hourly and active tapes once a day.  The eject is
what triggers the cloning to physical tape.  There are some other issues
that we've had to deal with on the VTL's, but all are minor compared to what
we used to have.

And, yes, it's also true that it might be inefficient in the tape use
because of the way the VTL allocates space for the virtual tape....again, a
small price to pay.

Still doing upwards of 200TB/week .... approaching 1 Petabyte/month.

--stuart

-----Original Message-----
From: Curtis Preston [mailto:cpreston at glasshouse.com] 
Sent: Sunday, May 13, 2007 10:58 PM
To: Liddle, Stuart; blaine_robison at yahoo.com;
VERITAS-BU at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Newbie to Netbackup using VTL

Stuart Liddle said:
>NO....Don't use Vault to duplicate from VTL to physical tape!!!

Looks like it's my week to disagree with you, Stuart. 
(Sorry.  I love ya' man!)

>We tried this, and in NB 5.1 MP6, Vault is a HOG!!  We were not able to
>Keep the drives spinning fast enough using Vault.  The best speeds we
saw >going to physical tape using vault was maybe 30MB/sec.  Usually we
got 
>around 10MB/sec or less....which is definitely not a good thing.

I've been able to get Vault to go MUCH faster than that. I would say
there are keys to doing it right.  The biggest one I see is that you
should either use multiplexing or not.  Don't mpx to tape (or virtual
tape) and then de-mpx when you copy.  VTL will suck just as bad as
regular tape when you do that.  So either preserve mpx when you dupe, or
don't mpx to your VTL (better).  Another key is having enough I/O
bandwidth in the media server to pull it off.

>What we ended up doing was using the built-in feature of our NetApp VTL
to
>do the cloning of the virtual tape to physical tape.  Now we are
getting
>much better performance of around 50 - 60 MB/sec.

Glad it got better. ;)

>The problem is that Vault has way too much overhead in doing the
copying of
>the data.

Again, I have to disagree.

>With the built in cloning function of the VTL, you just connect the two
>firehoses together and the data gets written from virtual tape to
physical
>tape.

There are also limitations to this approach.  While it removes the I/O
from the media server, you get a lot of wasted media if you eject your
copies every day.  In addition, the backup software has no knowledge of
the copy process, so if it fails, you're on your own for monitoring it,
etc. (It's not that I don't recommend this approach, I just wanted to
say that it does have limitations, perhaps the chief of which is that
Symantec will disavow any support on any issues you have.  Yuck.)

---
W. Curtis Preston
Author of O'Reilly's Backup & Recovery and Using SANs and NAS
VP Data Protection
GlassHouse Technologies