Maybe a dumb question

rdavila

ADSM.ORG Member
Joined
Aug 11, 2006
Messages
53
Reaction score
0
Points
0
Hi,

I have a lot of tapes OFFSITE that belong to the COPY STG POOL.
I understand all thos tapes are managed by DRM.

When I check which of those tapes can be reclaimed, there's about 30 tapes with over 85% reclaimable space.

The following query shows the 30 reclaimable tapes:
select volume_name as "Vol", stgpool_name as "Stgpool", pct_reclaim as "Reclaim%", est_capacity_mb as "Size MB" -
from volumes where pct_reclaim >= 85 order by "Stgpool"

Now the dumb question: How can I reclaim the space on those tapes if the tapes are OFFSITE?

If I run: RECLAIM STGP OFFSITE_DATA THRESHOLD=85 DUR=120
I can see a process running that is moving data from tapes that do not belong to the OFFSITE_DATA Storage Pool into a tape that does belong to the OFFSITE_DATA Storage Pool.

Example:
Code:
 Process Process Description  Status                                           
  Number                      
-------- -------------------- -------------------------------------------------
       5 Space Reclamation    Offsite Volume(s) (storage pool OFFSITE_DATA),   
                               Moved Files: 19403, Moved Bytes: 3,593,462,448, 
                               Unreadable Files: 0, Unreadable Bytes: 0.       
                               Current Physical File (bytes): 115,329,160,517
-
                               Current input volume: 000062.
Current output    
                               volume: 000075.

Volume 000062 belongs to my OnSite TAPEPOOL which is the "next" primary pool to where the Primary Disk pool migrates.

Volume 000075 belongs to the OFFSITE_DATA Copy Pool.

As I understand it, since the tapes are offsite and can't be mounted, TSM copies the small amount of data that exists on the offsite tapes from the primary pool into a new offsite tape. Then it should marke the offsite tape as VAULT RETREIVE since it no longer has active data.

The thing is, none of the tapes that are OFFSITE get marked for VAULT RETREIVE.


PS. Sorry for the long post but I wanted to explain everything as clearly as possible.

TIA for your help.
 
I think I found the problem.

I made the following query:
Code:
select volume_name as "Vol", stgpool_name as "Stgpool", pct_utilized as "%Usado", pct_reclaim as "Reclaim%", est_capacity_mb as "Size MB" from volumes where stgpool_name = 'OFFSITE_DATA'

And the result showed a lot of offsite tapes which had 0% utilized and 0% used.
I did a q vol on some of the offending tapes and the Status is set to Pending.

According to HELP QUERY VOLUME a Pending status means:
Code:
PENding
          Display volumes with a status of PENDING. These are volumes from
          which all files have been deleted, but the time specified by the
          REUSEDELAY parameter from the DEFINE STGPOOL command has not
          elapsed.

I checked the REUSEDELAY setting of the OFFSITE_DATA stg pool and it was set to 28 days. So that might explain why the empty tapes are not changing to VAULT RETREIVE.

I changed REUSDELAY to 1 to test it. If that solves the problem I'll just calculate a reasonable amount of days for REUSEDELAY (5 sounds good).

I'll post my findings.
 
Changing the REUSEDELAY to 0 temporarily seems to have done the trick. :)
I ran another RECLAIM on the OFFSITE_DATA stgp and now there are 27 offsite tapes in VAULT RETREIVE state.

I hope this info helps someone else with a similar problem. ;)
 
Generally you should set reusedelay to be about the same as the time you retain your TSM DB backups. This way, if you have to restore an old DB, the stgpool tapes from the old db backup haven't been overwritten yet.
 
Back
Top