Veritas-bu

[Veritas-bu] Volume Pools [recommendations please]

2006-04-26 09:27:48
Subject: [Veritas-bu] Volume Pools [recommendations please]
From: alex.wilkinson AT dsto.defence.gov DOT au (Wilkinson, Alex)
Date: Wed, 26 Apr 2006 22:57:48 +0930
    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