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 [EMAIL PROTECTED] ADSM Technical Coordinator - UNET University of Maine System
