What I did for multiple jobs (which may or may not be appropriate for you environment) was to define all my qtrees in the filelist for one class. Then turn on 'allow multiple streams' in the class and use the bpclient command to set the max_jobs to the number of drives we have (our global max jobs/client is set to 1).
Veritas doesn't (yet) support DAR (direct access restore), so when you go to restore a file, it will do a linear search starting at the beginning of the backup image, and going all the way to the end. If your backup image spans multiple tapes, it'll read them all, one after another. When DAR is supported it will be able to seek directly to the spot on the tape where your file is located.
Splitting up the backup based on qtrees, to minimize restore time was one of the reasons we configured it that way.
Below is our environment
Veritas DataCenter 3.4GA Patch J0850482 on Sun e250 2 400M procs and 512M ram ATL3000 Tape Library with DLT-7000 drives NetApp 760 Filer running OnTap 5.3.6R1 2 tape drives directly attached to the onboard SCSI port on Netapp Netapp is attached to LAN by gigabit ethernet
Scenario
We are backing up the nightly snapshots. We have a Netapp backup class. I have had to give each class the NEW_STREAM directive in order to get multiple jobs started, but unlike the other Veritas jobs, they line up in a queue and execute one at a time. Restores are quite slow, and while I can pick individual files out of a catalog, neither Veritas nor OnTap has any idea where they are on the tape. I have used the OnTap utilities to check status on the drive and seen it searching serially thru the tape for the file. The Veritas messages are very sparse. The first time I tried a restore, I had a 168Gb volume in one stream. It eventually took 5.5 hours to restore, and that was after I killed the job because I had no feedback from Veritas, having to reset the tape drives because they were downed by the kill. By splitting up the streams, I got this down to about an hour, but it is still slow enough to be an issue.
Does anyone have any idea what I may be doing wrong or is this just a issue with Veritas NDMP? Does anyone no if Veritas is planning on fixing this slow restore performance via NDMP? Will upgrading to Data Ontap 6.02 help any?
Thank you for your help, Mike