MOVE DRMEDIA & OFFSITE TAPES

[sfcc]

When attempting to re-insert tapes from vault to our tape library, we cannot find the right combination of command parameters for the MOVE DRMEDIA command to change the state from "VAULT" to something else. How do we get tapes that have been removed back into the library using the MOVE DRMEDIA command? Thanks.



Also, generally, what is the best way to manage tape rotation? We want to take a set of tapes to the vault every morning and replace them with the set that is currently in the vault. Is DRM the way to go or is there a better method?

 

[Fabio.Oliveira]

Tries the following command : move drmedia volume name wherestate=vaultretrieve tostate=onsiteretrieve

 

[sfcc]

Thanks for reply. Unfortunately, it still does not work. The command you suggested completes without errors, but DRM still thinks that tapes are in vault after command runs.

 

[krybczyk]

Why are they in vault status? The tapes coming back should be in vaultretrieve. Vault means there is still good data on the tape and it needs to remain offsite. Do q drm * wherest=vaultr and see if there are any tapes there. Those are the ones that should be recalled.

 

[sfcc]

Youve got me thinking that im going about this the wrong way.



All i need to do is rotate COPYPOOL1 and COPYPOOL2 in and out of my 3583 L36 Library everyday. I would like one COPYPOOL to be in the vault at all times and the other to be in the library. They will swap everyday. I was hoping to get this done with DRM but in my frustration with it forced me to look at other ways. For example :



# I tried using the "move media" command, expecting this command to checkout the tapes so that i could take them to the vault. Which it did. It worked.



move media * stgpool=COPYPOOL1 wherestate=mountableinlib wherestatus=full,filling ovflocation=Valt cmd="checkout libvol 3583_lib &vol status=private"





#However, the next command i was hoping to use to pull them back into TSM in the same COPYPOOL1 state that they left in. So that my nightly job didnt have to copy so much data over if it were to be scratch.



MOVE MEDIA * stgpool=COPYPOOL1 wherestate=mountablenotinlib wherestatus=full,filling ovflocation=InLibrary cmd="checkin libvol 3583_lib &vol status=private"





The command didnt ask for the tape. Thou it did :

11/25/2003 12:54:31 ANR6683I MOVE MEDIA: Volume 809AHR was moved from

MOUNTABLENOTINLIB state to CHECKIN



Which doesnt help me at all.



All im trying to do is get my tapes to the vault everyday. Rotate two COPYPOOLS. I would think it to be an elementary function. ???



Thanks in advance....for any advice.....

 

[krybczyk]

I'll give you the way we do it... maybe this will help out? If not , post back and I'll see if I can answer the questions you may still have.



Our backups run to disk and then are migrated down to a primary tape pool. At some time, we run a backup stgpool <primary pool name> <copy pool name> which does an incremental backup of the primary pool to the copy pool. After that is finished, we run a move drm * wherest=mo remove=bulk. This takes those tapes that were just created and moves them to the I/O station/hopper/cap. Then move drm * wherest=notmo and move drm * wherest=courier. This puts the tapes in Vault status. You can check with q drm * wherest=vault.



For returns, we do q drm * wherest=vaultr and request those tapes back from our storage vendor. When they come back, you can do a move drm <volser> wherest=vaultr then move drm * wherest=courierr. This deletes them from the storage pool and then can then be checked in (with a checkin command) as scratch.



Using this method keeps one storage pool (the copy storage pool) offsite and one storage pool (primary pool) in the library for high availiblitiy.



The first time you run the backup stgpool, it's (obviously) going to generate a lot of tapes. But when you run the backup stgpool after that, it's an incremental copy so you won't be generating a lot of tapes, depending on how much data you are backing up.



There is a really good RedBook at www.redbooks.ibm.com called Disaster Recovery Strategies with Tivoli Storage Management. I think chapter 8.6 and 8.7 may be able to explain better if I haven't.



Let me know if you still have questions. I can't guarantee I'll be able to answer them, but I'll try. Good luck!!!

 

[lzotto]

DRM Media cannot be moved from the vault state to the mountable state with the "move drmedia..." command.



But I think this will work:



1st) Do a checkin of the volumes of your copypool that is in VAULT state.

After the checkin the tapes are still shown as VAULT by the "query drmedia" command.



2nd) Now update the required volumes from "access=offsite" to "access=readwrite": "upd volume <VOLNAME> access=readwrite". This should move your volumes back to the mountable state.

 

[lzotto]

Using "move media..." instead of using " move drmedia..." you must checkin the tapes into the library after the "move media..." command successed.

Therefor use the command file written by your "move media.." command. The option "cmd" only generates a command file if the option "cmdfilename" is not given a standard filename is used.

The command filename can be executed using the tsm command:

"macro <path:\filename>"



For the checkout command you do not need to use the option "cmd". The "move media * <stgpoolname> wherestate=mountableinlib..." has the option "remove=yes" as standard. If you want to put the media removed to the I/O slot of your library just add "remove=bulk" to your command.

The same way add "search=bulk" to your "cmd" option to checkin the the volumes via the I/O slot.



I hope one of the 2 soltutions I wrote helps you!

 

[sfcc]

This is great information that you've given to us. We've tested it out and it's working great. Thanks very, very much!



What's your recommendation for handling the tape containing the DB? Should we use DRM for that or use a similar approach for the DB tape that we use for the copypools or some other means? Thanks.

 

[lzotto]

If the DRM license is present I would you DRM to move the DB Backup offsite. In my oppinion it's the easiest way to perform this task.



Best Regards

Laurent ZOTTO