Volume in library cannot be assigned a status of SCRATCH

Update:

Instead of loading them as scratch, I checked that tapes as status=private. Now, it is showing in the list of "q libv", but when I try to do "q vol" it is not showing any information.

q libv output

Library Name: L3494B
   Volume Name: 005074
        Status: Private
         Owner: 
      Last Use: 
  Home Element: 
   Device Type: 
Cleanings Left: 
    Media Type: 

Select allOpen in new window

q vol output for the same volume:

ANR2034E QUERY VOLUME: No match found using this criteria.

Select allOpen in new window

What can be the issue with this, whether something has happened to the data on it? how can I verify the same and let TSM know about that tape.

Thanks
virgo

Ok, I will verify that. Also, one more thing - from last one month library/tsm is using lot of scratch tapes suddenly. The scratch tapes reduced from 180 to down to 0 in last one 29 days. Actually, I made 2 changes during last month.

1) I changed the retention policy settings for one of our windows backup pool which we discussed yesterday in the thread ID: 37967576 "Regarding TSM retention policies"

Policy    Policy    Mgmt      Copy      Versions Versions   Retain  Retain
Domain    Set Name  Class     Group         Data     Data    Extra    Only
Name                Name      Name        Exists  Deleted Versions Version
--------- --------- --------- --------- -------- -------- -------- -------


WINDOWS   ACTIVE    WINDOWS   STANDARD  No Limit No Limit       60      60

WINDOWS   WINDOWS   WINDOWS   STANDARD  No Limit No Limit       60      60

Select allOpen in new window

last month I changed the value of "Retain Extra Versions" from 30 to 60.

(2) change was - I changed the value for deleting volhist from 32 to 91 days (this I changed as I want to predict the tape usage)

I am sure, that first change is causing me using more scratch tapes, but I just want to verify whether it is first change or second change causing this? Can you help me in this?

Thanks
virgo

You're right, the first change will use up the tapes if many huge files are updated and thus saved daily. That's what we discussed yesterday : + 30 x 1.5 TB is quite a lot.

The second change will not cost a thing. The volume history is just a file on disk, and 90 days shouldn't give more than a few MB.

It is only a historical record of tape state changes which occur anyway - kept as a record in the history or not.

ohh right, I was thinking the same way, so that means I kept the retention of 60 days of the file versions instead of 30 days...correct? So, once the 60 days retention is crossed for the files, the expire inventory process will remove the files from the tapes and free up the space right..?

So, I guess I will get all the tapes back to my scratch pool soon. I am attaching the output of one of the backups of DB of the exchange for which the backup dates are there. So, in this case, the expire inventory will remove the files starting from 17th of this (May) month ... right? and then space will be freed on primary tape pools as well as copy pools and I will get tapes back from offsite ... right ?

So, previously when the value was 30, it was deleting the inactive backup version in 30 days, and as I changed the value to 60, it will delete when it will cross 60 days, which will going to happen on 17th may.... right ?

This is what I understood. Correct me if I am wrong on this.
backup.txt

So, if I change the value back to 30 now, whether tomorrow's expire inventory process will get me the space and tapes back much faster ? as compared to the normal expiry which will be running from 16th May.

What process will get me tapes/space back as early as possible so that I can fill up my scratch pool?

Any suggestion on that?

thanks
virgo

Reducing RETEXTRA to 30 will free up all at once the space occupied by all versions older than 30 days,

RETEXTRA=0 will free up the greatest possible amount of space, of course, but consequently you will then only be able to restore the active version, not previous versions, because these are all gone.

Ok,, thanks for the explanation.

Now back to original question, ID ID: 37969027 - I ran that query for the tape volume for which I got that scratch assignment error. I see that all the tapes as showing as type "BACKUPFULL"  and dates are showing from last 15 days, so I think I cant delete the history for that volumes ... right ? following are the details:

005074 - 2012-05-01     BACKUPFULL        
005077 - 2012-05-11     BACKUPFULL        
005112 - 2012-04-30     BACKUPFULL        
005172 - 2012-05-06     BACKUPFULL        
005289 - 2012-05-05     BACKUPFULL        
005290 - 2012-05-04     BACKUPFULL        
005445 - 2012-05-02     BACKUPFULL        
005560 - 2012-05-07     BACKUPFULL        
005714 - 2012-05-10     BACKUPFULL        
005807 - 2012-05-09     BACKUPFULL        
006176 - 2012-05-08     BACKUPFULL        
006250 - 2012-05-03     BACKUPFULL        

so is it ok to keep these tapes onsite, instead of sending them back again to offsite. Also, if I ran the command you gave "DEL VOLH T=DBB TODATE=TODAY-30", this will not delete the backup on these tapes as it is within 30 days of period ... right ?

what you suggest on this?

thanks
virgo

Ohh..I think I messed up, I was going through some forum and found following link, which was showing the way of deleting a single volume from the history:

http://adsm.org/forum/showthread.php?16097-del-volhist

then i ran this command "del volhist type=DBB volume=005112 tod=+0 force=yes", which I think removed the full database backup of last 15 days instead of single volume, which I pasted in above thread and I saw that suddenly 12 tapes (all of them above) came back to scratch pool.

Is that I have created any problems by deleting the db full backup of last 15 days, what impact it can have on my backups?

virgo

when I tried with "remote" option given in the thread, it erred out unknown type, and then I put DBB, where I think i messed up with the DB backups? kindly help me in this ?

OK, I don't know what kind of expert gave that suggestion.

I told you in my first comment that it's not possible to delete single volumes.

But don't panic, DEL VOLH never deletes the most recent volume in a DB backup series.

Do nothing particular, run your scripts as always so new DBB tapes will be created, take them offsite when requested, as usual.

Check whether the tapes in question are "SCRATCH" now, and if they aren't run against each of them:

UPD LIBVOL L3494B volumename STATUS=SCRATCH

how can I query the latest DBB backup, just want to verify it has not removed the latest one?

Q VOLH T=DBB

It says - ANR2034E QUERY VOLHISTORY: No match found using this criteria.

I think I have deleted the latest backup also, as in that command i have given tod=+0. Is there any other command for that?

OK, you used the "Force" option. Too bad!

The only thing you can do now is running a DB backup asap, or wait until your script runs the next time. It contains a DB backup, if I remember well.

yes, my script contains the DB backup snapshot for onsite and full DB backup for offsite.

I have one more question (last question) regarding the process of inventorying the tapes. Is there a standard process of doing a tape reconciliation in TSM for onsite and offsite tapes.

Thanks
virgo

What do you mean with inventorying/reconciliation?

If you mean reclamation - TSM does this automatically as soon as the threshold is reached, you can't start it by hand. I assume that the threshold will be reached very soon, because you're expiring a lot of data.

You can run EXPIRE INVENTORY prematurely to speed things up.

Ok, got it. Giving points