TSM Lost Tapes

[erempel]

I discovered that I have 14 Tapes offsite that TSM has "forgotten" about.

The tapes are not listed in drmedia, libvolume, volumes, media or volumehistory

tables. I can easily get the tapes back on site, but I want to be sure that there is

not needed data on the tapes.



In theory, TSM should never have lost track of the tapes, so the "In theory

they are empty" does not apply. I want to audit these volumes.



I can not audit a volume unless it is part of a storage pool, but I can't find any

way to place the tape into a storage pool, nor would I know which one to place

it into, even if I could.



How do I audit a tape the TSM has lost track of?

 

[alixf]

I suggest you to do checkin for the lost tapes:

CHECKIN libv tapelib(library name) xxxxxx((volser number) status=scratch search=no checklabel=no devt=xxxx (device type)

 

[rcard]

Sounds like you've changed the DRM state at some time, (probably from 'vaulretrieve' to 'onsiteretrieve'?), which would effectively remove them from DRM, but then you haven't checked them back in to your tape library. If 'q vol stg=<storagepoolname>' doesn't show these tapes, then they don't belong to any storage pool and therefore are scratches! Just check them in!



Rich.

 

[erempel]

Thanks for all of the help. I have found these volumes. They are in the drmedia table,

but they do not have a storage pool association. They are database backup tapes.



Evan,

 

[sherrysun]

Evan,



I am having the same problem as you had. Those are the tapes that I have checked offsite, how do you check the drmmedia table to find out they were there?

and what did you do with them? check them back in?

I would like to know the way to prevent it,



Thanks for the help.



Sherry[email protected]

 

[klebesco]

when you do a q drmedia the vols appear to be sorted by vol BUT in fact are not. As you have found out by now the DBbackup vols are last and in reverse chronological order.



my way of not tricking myself is by replacing the q drmedia with a simple script I call DRVOLS

which reads:



select volume_name, state from drmedia -

order by volume_name



hope this helps!



Kurt



:lol:

 

[sherrysun]

That's a really useful tip, thanks.



But that still doesn't show the tapes that I "lost".

I have notice that always the last disk or disks under "q drm" will disapper from the list. Are those database tapes? They would stay in drm for a few days, and then gets "deleted", why is that? and what should I do about it?



Thank you or any guru that might have an answer for me.



Sherry



[email protected]

 

[heada]

The DBBackup tapes are tracked in 2 locations. The Volhist file and drm.



I had the problem where I had DRMDBBACKUPEXPIREDAYS set to 35 and I was deleting the volhist older then 30 days. Sometimes (and I could never figure out why or when) TSM would 'lose' one of the DBBackup tapes. I ended up changing the delete volhist command to any tape older then 40 (more then DRM should know about).



I also changed how I generated my outgoing and return lists. I used to read what tapes where used out of the volhist. I now do 2 simple commands to get what tapes are outgoing and what tapes are comming back.



q drmedia "*" wherestate=mountable (shows tapes that will be sent offsite)

q drmedia "*" wherestate=vaultr (shows tapes that will come back)

I then move the tapes.

move drmedia "*" wherestate=mountable todate=vault source=ddbackup

move drmedia "*" wherestate=vaultr tostate=onsiteretrieve



This seems to work for me. I no longer 'lose' tapes at the vault.



-Aaron

 

[sherrysun]

Very helpful, thanks



I will change my del volhist to longer than dbbackup expiration length.

I'm confident that is the cause.



Sherry