I am not sure I follow your plan. If you have tapes in a tape pool say
"production data" and these tapes are vaulted out of your robot to a
offsite volume group say "company_offsite", these tapes should remain in
the original tape pool by design. If the tape is in the robot or out,
you still want the tapes to be grouped together with other tapes that
have the same type of data.
 
You could create separate vaults for each tape pool you have and eject
them out of your robot to a offsite volume group and slot number. The
problem comes in though that each offsite group has its own vault slot
number range. So if you have 1 large tape library with slots 1-10,000
and you have 5 different vaults defined and they all begin with slot one
then you need to keep them on separate tape racks. This gets very messy
at first. BUT the way vault is designed is that if you vault all tapes
into the same offsite volume group then all tapes can reside starting at
slot 1 and work their way up to slot 10,000. But they are still separate
in a way because the tapes still sit in different tape pools.
 
We have about 5000 tapes at our one location but these tapes consist of
many types of data (exchange, production, NDMP etc). But I have one
vault defined that ejects all the tapes to the same offsite volume group
starting in slot 1. The tapes get filed away together, side by side,
even though they are from different volume pools. When these tapes go
scratch they show up on my one scratch list and they get pulled and
moved to a scratch shelf then they go into the robot. If I had separate
vaults defined I would have to run many vaults each day or week and have
many different scratch reports (since the vault only prints out the
scratch list for that offsite volume group defined) to worry about each
day/week. Too much hassle.
 
Just be careful though in your design because vault cannot eject
different types of media in the same vault, for example if you have LTO
and DLT tapes. These need to have separate vaults for each media type or
they will never get moved to the offsite site volume group correctly.
They get assigned a slot number but never get moved to the offsite
volume group and thus will not show up on a scratch list when they go
unassigned.
 


Greg Hindle 
Constellation Energy 
Data Management & Recovery 
Room 500, 1068 N. Front St. 
Baltimore, MD 21202 
410-470-1552 
greg.hindle at constellation.com <mailto:greg.hindle at constellation.com>  

 

________________________________

From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of
Sponsler, Michael
Sent: Wednesday, October 11, 2006 11:38 AM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] Managing Tape Rotations



I'm trying to work out a good tape rotation policy, and I'm trying to
get vault to work the way I want it.  Basically the tapes are replaced
every month, and rotated back in every 6 months (they get erased when
rotated back in).  With Vault, I've noticed that the "vaulted" tapes
remain in the same volume pool that they were assigned to but are moved
to a different volume group.  With out unassigning the tape, and
basically losing the data on said tape, is there a way to move the tape
to a different Volume Pool (not volume group) while the tape is vaulted
/ moved off-site?  I'm dealing with hundreds of tapes, and my Volume
pools are becoming cluttered with vaulted tapes.

Is there a better tape rotation system to use besides Vault, and what
would any of you suggest? 

-- 
Mike Sponsler 
Northrop Grumman 
Michael.Sponsler at ngc.com 
(703) 968-1302 
12900 Federal Systems Pkwy 
Fairfax, VA 22033 


>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the
addressee.  If you are not the intended recipient, do not use the information
in this e-mail in any way, delete this e-mail and notify the sender. CEG-IP2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061011/6d13949a/attachment.html