KISS = Keep It Simple, Stupid!

It's easy to over-manage NetBackup, because it lets you.  I recommend 
that you keep things simple, and deviate from the simple when it's 
evident that you should.

If the NetBackup pool contains all of your assigned tapes and the 
Scratch pool contains all of your available tapes, life is simple.  How 
many tapes are in use? Count the number of tapes in NetBackup.  How many 
tapes are available for backups? Count the number of tapes in Scratch.  
All free tapes are available for the next backup.

Cleaning tapes, if any, will be in pool NONE.  I use another pool for 
"suspect" tapes ... tapes that have had "an event" such as a read or 
write error.  If on v6.0, you probably have pool for catalog backups.  
If you duplicate/vault tapes, you probably have another couple of pools 
(one for catalog backups; one for data) for your catalog and image copies.

Why make more pools?  One reason might be to insulate free tapes in a 
pool from others.  For example, in my shop our Oracle Agent backups take 
precedence over file system backups.  We don't want independent file 
system backups "filling" a tape pool, possibly delaying backups and 
causing our archive redo log spaces to fill.  I'm sure there are other 
reasons for more pools, but in general, I recommend: KISS. :-)

cheers, wayne

Wilkinson, Alex wrote, in part,  on 4/25/2006 8:46 PM:
> What is "best practice" with regards to Volume Pools ?
>
> We are thinking of using a single Volume Pool for all of our data tapes.
> Is it good practice to use the "Netbackup" Volume pool for this situation ?
>