On 22 Mar 2002 at 13:37, Joni Moyer wrote, in part:
> Reclamation is set for 60 on both the onsite tape pool and the copy
> pools(offsite).
If you have enough tape drives so that reclamations don't interfere
with other need for drives, then this is fine. I don't, so my tape
pools are set at reclaim=100 for most of the time, and at reclaim=nn
for the times I don't mind reclamations starting.
In general reclamations are independent of your protecting your server
and client data, except that (1) you need to have enough non-full tapes
to write new data, and (2) restores are generally faster from
relatively full tapes because the generally require fewer tape mounts.
> ... and then in turn the reclamation for that volume fails because it
> cannot be mounted in the silo. I didn't think it was possible to run
> reclamations for the tapes that are in the vault. How do I prevent
> reclamation from trying to reclaim these volumes when they are also
> technically recognized in the copy pool?
I'm not sure why you get the failure. You surely can reclaim files from
offsite tapes ... *SM simply mounts primary volumes (onsite tapes) in
its building of a new copypool tape. I've not tried to reclaim a
copypool volume that was onsite; does *SM then use the copypool volume
directly? If so, it might have been confused by the sequence (1)
determine reclaim of a tape is to proceed, (2) your mark tape as
offsite, and (3) try to mount tape, only to find tape is set with
access=offsite. Pure speculation.
> I also have many volumes in the offsite copy pool that are in the status
> of pending and they are in the offsite vault. Does TSM interact with
> TMS to bring those volumes back to the copy pool in the silo or do I
> have to run a job to do this?
The pending status exists in case you have a disaster and need to
restore an old copy of your DB. You want the tapes, as set in that old
DB copy, to continue to hold the expected data and not be overwritten.
So you set your reuse delay to what makes sense for your DB backups. If
you might someday want to restore a DB backup that is 7 days old, your
reuse delay must be at least 7. (The alternative is that you can't
trust what's on any tape and so must mount and audit all of them.
Yeck).
I don't have or know TMS, but here is some of what goes on:
Your (normally status=full or filling) tapes are set as access=offsite
when you take your tapes to "the vault" (DRM, if you have it, has a
couple of intermediate steps). Eventually, because of inventory
expirations (and reclamation), the tapes become status=pending. Once
your reuse delay completes, the tapes become status=empty ... still
with access=offsite. Now you have some logically empty tapes in your
vault.
At some point you decide to retrieve these for reuse (again, if you
have DRM, there are a few states the tapes can go through). Once you
have returned the tapes, (remember they're already status=empty), you
update their *SM state to access=readwrite (assuming you're using a
private pool and not scratching tapes you're done with). (Sorry for the
bad grammar!)
If you need it, there is a "location" field that you can use with the
update volume/volhist commands to help keep track of where the tapes
are really located (if you don't use DRM). With DRM see the Q DRMEDIA
and MOVE DRMEDIA commands.
Hope this helps, wayne
Wayne T. Smith ADSM AT Maine DOT edu
ADSM Technical Coordinator - UNET University of Maine System
|
