0n Wed, Apr 26, 2006 at 10:57:48PM +0930, Wilkinson, Alex wrote: 

    >    0n Wed, Apr 26, 2006 at 12:49:25AM -0400, bob944 wrote: 
    >
    >    >Alex, you'll get a dozen recommendations.  This is the right one.  :-)
    >    >
    >    >> 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 ?
    >    >
    >    >Yes to the first, no to the second.  
    >    >
    >    >Offline catalog backup tapes in NetBackup.  Everything else in
    >    >"dsto-mlb".
    >    >
    >    >-  "dsto-mlb" is a made-up name to suggest that you name your primary
    >    >pool after your datacenter (and supposing DSTO and Melbourne and that
    >    >you have, or may later have, other datacenters).  The intent is to 
have
    >    >a simple way to keep your DC's tapes separate from "dsto-prth"'s tapes
    >    >during the inevitable consolidation or other circumstance that
    >    >co-mingles your and foreign tapes.
    >    >
    >    >-  Practically, you'll still have a None pool (cleaning tapes, tapes
    >    >with errors you don't want used until you test or toss them).  And
    >    >probably a scratch pool, a duplicates pool or two, a duplicate catalog
    >    >backup pool, the goofy DataStore pool unused.  
    >    >
    >    >-  I always suggest a "test" pool.  Keeps your production pool from
    >    >accumulating junk test data, frees you to do any testing and expiring
    >    >you need to without risk of filling/tying-up/expiring production 
tapes.
    >    >Test what you want, expire the tapes when done and let them go back to
    >    >scratch.
    >    >
    >    >-  There _are_ reasons to have separate pools.  Find a logical 
division
    >    >_with_ a reason that justifies the administrative and operational
    >    >burden.
    >    >
    >    >- - Customer privacy.  Do you have two clients whose data should not 
be
    >    >mixed?  Army and Navy pools, then.  Related to this is restricting
    >    >access to a pool to a specified host (media server) if there's a 
Really
    >    >Good Reason to do this.
    >    >- - Minimizing collateral damage.  Does someone occasionally leak
    >    >classified info onto an unclassified system--requiring you to destroy
    >    >all unclassified backups which might contain it?  Subdivide in any way
    >    >that makes sense to minimize loss of the rest of the backups.  
    >    >- - Related to the above, is there a project or client whose backups 
may
    >    >need to go elsewhere tomorrow?  Just eject all the tapes in that pool
    >    >and send them on their way with 100% of their info without losing any
    >    >that's not theirs.
    >    >- - And a third variation on the going-offsite theme:  Maybe a
    >    >given-to-legal pool for duplicating backups that go off to some other
    >    >entity and may not return...  
    >    >- - Availability assurance.  Have a really small library and need to 
be
    >    >positive there'll be enough tape for the big weekend database backup?
    >    >Separate, stocked-up "oracle" pool so that other backups/users can't 
use
    >    >up those tapes.  Or a separate "user" pool if you allow user
    >    >backups/archives and that's the group that might use up your free 
space
    >    >(though this method loses a lot with the advent of automatic draw 
from a
    >    >scratch pool).
    >    >
    >    >There are undoubtedly other good reasons, but if you insist that 
someone
    >    >come up with a rationale that can't be met any other way--not just
    >    >something that _sounds_ logical.  It makes me crazy to see Full and
    >    >Incremental pools, or Unix and Windows ones.  Remember that pools are
    >    >another multiplier of tapes-in-use, alongside multiple media servers,
    >    >mux/non-mux and differen retention levels.
    >    >
    >    >You're on the right track.  Simplify.  Let the computer manage what it
    >    >can and save your brain for important things.
    >
    >Awesome detailed reply Bob. Thank ! Much appreciated. However, I have a few
    >quick questions still:
    >
    >1. You say tapes with errors will be moved to the "none" pool. I was under 
the
    >   impression they would be 'frozen' and left in their orginating Volume 
Pool ?
    >   Can you please clarify what you mean by this.
    >
    >2. What is the "DataStore" Pool actually designed to be used for ?
    >
    >3. You mention that cleaning tapes would go into the "None" pool. I was 
origally
    >    thinking of creating a "CLN" pool. Bad idea ?
    >
    >Cheers and thanks to everyone who is responding. Please keep your opinions 
and
    >ideas flowing in. I am _very_ interested !
    >
    > -aW

Oh and another question:

Why would I need a 'duplicates' and 'catalogue duplicates' pool ?

 -aW