orphan volumes -- how to reuse them

[rogwall]

Running the following

select libvolumes.volume_name from libvolumes where libvolumes.status= 'Private' and libvolumes.volume_name not in (select volumes.volume_name from volumes)



that is giving me the list of some volumes. When I do "q vol <vol_name>" on of of those volumes, it says No match found.....When I do "update vol <vol_name> access=readwrite" it gives me the message "...Volume <vol_name> not dfefined in a storage pool, return code 11.."



My question:

1. What are those volumes?

2. If those are orphan volumes, how can I make them useful again?



Thanks in advance.

 

[n9kws]

Couple 0f Questions:



1) Are you running volhist delete ?

2) Do you have TDP's in installed on any client?

3) Are you using any of the V5.6 Sysback to TSM backup features?

4) Has anyone run filesets to the server?



I am sure I am missing others, but we can start with these.

Basicly before we can declare them orphans, we have to make sure they are not in use by other facilities. After we rule out all other options, then they are orphans an can be dealt with.



I go about finding these, by doing several commands, they are Q VOL <volser>, Q LIBVOL <lib> <volser>, Q DRM <volser>. If it does not appear in any of these, then I have to check on the questions listed above. If it's in the library, I can check it out and back in to make it scratch, but other situations call for other steps. YMMV.



Andy.

 

[may]

these can also be:



- DBBackup

- BackupSet

 

[rogwall]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>Couple 0f Questions:



1) Are you running volhist delete ?

2) Do you have TDP's in installed on any client?

3) Are you using any of the V5.6 Sysback to TSM backup features?

4) Has anyone run filesets to the server?





</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



Our primary TSM admin is off on a long term vacation and before leaving I was told that Andy is a guru on tsm on adsm.org. I am honored to see him involved in my question, thanks.



Find my answers inline below...



1) Are you running volhist delete ?

No.



2) Do you have TDP's in installed on any client?

No.



3) Are you using any of the V5.6 Sysback to TSM backup features?

No,



4) Has anyone run filesets to the server?

How can I verify that?



it is TSM 5.2.2,0 on Solaris 8.

 

[rogwall]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>these can also be:



- DBBackup

- BackupSet</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



True, when I do "q libv" I see some of those are in DBbackup, some in BackupSet and some have no value in "Last use" column. Confusion....



thanks

 

[patux]

that looks like default install.



if you don't run a volhis delete you may run a checkin in scratch mode to reuse those volumes.



be carefull,



- dbbackups are not shown in q vol, but in q libv

 

[rogwall]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font class="pn-sub">Quote:</font><HR></TD></TR><TR><TD><FONT class="pn-sub"><BLOCKQUOTE>

if you don't run a volhis delete you may run a checkin in scratch mode to reuse those volumes.

</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR></TD></TR></TABLE>



we regularly run "checkin" to checkin tapes from bulk to scratch, that come from vault/vaultretrieve. So the cycle goes on. I am worried if these tapes (specially the ones with no status in "Last Use" column of "q libv") will ever be expired and/or reused by TSM without manual exercise.



thanks

 

[n9kws]

After you run Q LIBVOL you see volumes listed as private and with no "last use" info in that column, right? Hmmmm, if these tapes cannot be accounted for by any other means, then they may very well be lost to TSM. I have had this problem before and it was becasue I was running vol hist delete, and this caused them to drop out of the system in a way that TSM is not designed for. I would be looking into that angle further, becasue TSM should not lose track of tapes, ever!



To reclaim them you will have to check them phyically out of the library, and recheck them in as scratch, simply running checkin will not work becasue they have a private status. Depending upon your library you might be able to change the status to scratch using mtlib.



Overall be careful, if these tapes are supposed to be in use be something you will lose data unless you do all the research necessary to rule out the other possiblites.



Andy.

 

[rogwall]

there is infact 1 volume that is with no Last Use status:



tsm: TSM>q libvol * CA0120

Library Name Volume Name Status Owner Last Use Home Device

Element Type

------------ ----------- ---------- ---------- --------- ------- ------

LTO3584 CA0120 Private TSM 1,194 LTO



As you said, I will have to check it out physically if it really is inside....



thank you all.

 

[dustypaint]

Rogwall,



Run theses this script that checks for orphaned volumes then checkout the volumes that are displayed and then run checkin.



select volume_name from libvolumes where status='Private' and last_use is null and (volume_name not in (select volume_name from volumes) and volume_name not in (select volume_name from volhistory where type not in('STGNEW','STGDELETE','REMOTE')))



Hopr this works for you.

 

[miscman99]

One thing that can cause this is checking in an unlabeled volume. If the volume returns to the private with no last use, check the volume out, then run label libvol with the overwrite=y option. I have seen that as the cause way to omany times.