[Veritas-bu] Volume Pools [recommendations please]
2006-04-26 09:27:48
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Veritas-bu] Volume Pools [recommendations please], Wilkinson, Alex
- [Veritas-bu] Volume Pools [recommendations please], Mansell, Richard
- [Veritas-bu] Volume Pools [recommendations please], WEAVER, Simon
- [Veritas-bu] Volume Pools [recommendations please], WEAVER, Simon
- [Veritas-bu] Volume Pools [recommendations please], WEAVER, Simon
- [Veritas-bu] Volume Pools [recommendations please], Paul Keating
|
|
|