The village idiot is back-

[feedmetwinkies]

Ok I had exported some media that was mountable- by doing the following-

move drmedia * wherestate=mountable remove=untileefull tostate=vault



Then I wanted to import the media so using my isc web interface I checked the volumes back -



Issues a q drm - 2 tapes were vaultretrieve - I did the following- move drmedia 000024l3 wherestate=vaultretrieve tostate=courierretrieve



Now I can't see the media any more when I q drm - and when I do q vol tape 24 is missing- I have tried q vol 000024l3 - no match found- can anyone help-



what I was basically trying to do was get media from vault or vault retrieve back in the mountable state- Can anyone help?

 

[heada]

That tape is now scratch and not defined in any pools or in DRM. You can check it into your library as scratch and use it as a brand-new tape.



-Aaron

 

[feedmetwinkies]

<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> That tape is now scratch and not defined in any pools or in DRM. You can check it into your library as scratch and use it as a brand-new tape.

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



Is this tape scratch because of something I did?



Ideally when I issue a q drm and I get a listing of tapes that are mountable- Those are the tapes that should be shipped offsite right?



Once the tapes are sent back from offsite storage how should I get them from Vault or vaultretrieve to mountable again without making them scratch?

 

[heada]

There are 3 real states of tapes for DRM (you can use more, but 3 is all you really need)



mountable - onsite in the library.

vault - offsite

vaultretrieve - empty and ready to come back onsite as scratch



When you perform a backup stgpool (or db backup) a tape is added to the mountable state. These are the tapes that should be sent off with the next batch of tapes (send them off with "move drmedia wherestate=mountable tostate=vault") The tapes will sit offsite and the data will age. As some of that data expires, reclamation can reclaim a tape or it can just sit there until all the data has expired. Once the tape is empty, DRM will change the state to vaultretrieve. Any tape in the vaultretrieve state can be moved back on site and reused as scratch (move drmedia wherestate=vaultretrieve tostate=onsiteretrieve) This move will automaticlly remove the volume from the stgpool it was in and from the database. This volume is now scratch and can be reused. It can be checked into the library as scratch.



Lather, Rinse, Repeat. Thus is the life of a tape volume...



-Aaron

 

[feedmetwinkies]

Aaron your the man- thank you so much- you managed to make this village idiot understand! Bless you man Bless you!

 

[itdrew]

Aaron does lend some good advice and is a great addition to this site, no doubt.



Quick question though regarding the post below just for clarity: Isn't the state of the tape actually courrier retrieve, not vaultretrieve when the tape comes back?



Normally when the offsite tapes come back for scratch, I am changing the state from courierretrieve to onsiteretrieve with:



move drmedia * wherestate=courierr tostate=onsiter source=dbs wait=yes



Thanks,



Drew

 

[heada]

If you have a courier defined, then the tape will enter the courierretrieve state. If you don't, then it wont. The only states the tape will always go to are the 3 mentioned before. All the other states are based on if you have those states defined. A tape will actually go through the complete path of DRM, but only stop where you have something defined. A tape will go through mountable, courier, vault, vaultretrieve, courierretrieve, onsiteretrieve and then be deleted (STGDEL in volhist) It will stop at vaultretrieve if you don't have a courier defined and stop at courierretrieve if you do.



The states as defined by "help move drmedia" are:



mountable

notmountable

courier

vault

vaultretrieve

courierretrieve

onsiteretrieve



Then again, I could be wrong.



-Aaron



P.S. Thanks, I started with ADSM back in Aug of '99 and have been trying to understand it ever since. Anything I know is from others helping me out and I figure I should help others as much as I can.

 

[CBell]

Excellent info, and by the way, this stuff can also be found in the RedBook "Disaster Recovery Strategies with Tivoli Storage Manager", though the concept was explained rather well here.