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:[EMAIL PROTECTED] Sent: Sunday, May 13, 2007 10:58 PM To: Liddle, Stuart; [EMAIL PROTECTED]; VERITAS-BU@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 _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu