Moving media to offsite

[yquirion]

Dear all,

We have space problem in our 3584 library and we would like to move some backup media to an off-site location and replace them by scratch (empty) volume.

I googled a little about this and find some information how doing that, but most of them were talking about DRM. We don't have DRM. I would like to know if there is an easy way to move medias we don't need at this time into an offsite location without loosing its data.

I will also need to know how to reload/re-checkin the media into the library if we need to restore data that are on those off-site medias. In that case, I supose TSm will ask for a specific media and do a "reply" after the requested media has been checked back into the library.

Thank you and best regards,
Yanick

 

[hogmaster]

the commands that you need are:
checkout libvol
and
checkin libvol
and use the select below to find some volumes to remove from the lib.
select VOLUME_NAME,PCT_UTILIZED,STATUS,LAST_WRITE_DATE from volumes where status='FULL' order by LAST_WRITE_DATE

If you have any tapes att all with space left try to move data from tapes that are full but with a low pct_utilized value, that will give you some more space.
You can use the select below to fine the volumes with the least data and move that data to a new tape
select VOLUME_NAME,PCT_UTILIZED,STATUS,LAST_WRITE_DATE from volumes where status='FULL' order by PCT_UTILIZED
take the tape at the top of the list and issue
move data VOLUME_NAME.

When you are done check tat your reclamation threshold values are ok. Then check for nodes that are storing a lot of data
by issuing q auditocc.

Good luck

 

[sjl]

Using the DRM commands (move drm) is the optimal way of doing it, but I'll freely admit that I don't know all the ins and outs of licensing - I seem to remember that it requires TSM Extended Edition, but I won't swear to it.

If using the DRM commands isn't an option, MOVE MEDIA is another command to look at; checkout/checkin libvolume will move the tapes out of (or into) the library (from the TSM perspective, and optionally physically as well), but won't update the access to the volumes.

If you're checking out copy pool volumes, I'd recommend also doing UPDATE VOL (volume name) ACCESS=OFFSITE, so TSM knows not to try to access it. This won't work for primary pool volumes, and is automatically done by MOVE DRM.

I am speaking from personal experience when I say, in the strongest possible terms, that you do NOT want to move out primary pool volumes unless you have no other choice. It introduces a whole world of pain; you really don't want to go there.

 

[yquirion]

Dear hogmaster,

Thank you for your quick answer. I have another question for you. Because we don't have copy storage pools, we cannot use any DRM command (based on what I read). So I take a look at the "move media" command, which seems interesting to me. Have you already use that command before?

If I'm using the checkout/checkin libvol as you suggested, should I change the "ACCESS" for the volume I will remove to prevent TSM asking for those volumes? There is an option called "offsite" for ACCESS parameter, but only works on copy stg pool. What will happen if a restore need a volume I checkout of the library? Will TSM ask me to check this volume in?

Here is a command that I think may do the job. If you have any comment, please let me know:
move media * stgpool=sofe-pool days=60 wherestate=mountableinlib wherestatus=full remove=bulk ovflocation=offsite/room2020 cmd="update vol &VOL access=UNAVailable" cmdfilename="/home/tsmadmin/offsite/volumeslist"

Thank you again,
Yanick

the commands that you need are:
checkout libvol
and
checkin libvol
and use the select below to find some volumes to remove from the lib.
select VOLUME_NAME,PCT_UTILIZED,STATUS,LAST_WRITE_DATE from volumes where status='FULL' order by LAST_WRITE_DATE

If you have any tapes att all with space left try to move data from tapes that are full but with a low pct_utilized value, that will give you some more space.
You can use the select below to fine the volumes with the least data and move that data to a new tape
select VOLUME_NAME,PCT_UTILIZED,STATUS,LAST_WRITE_DATE from volumes where status='FULL' order by PCT_UTILIZED
take the tape at the top of the list and issue
move data VOLUME_NAME.

When you are done check tat your reclamation threshold values are ok. Then check for nodes that are storing a lot of data
by issuing q auditocc.

Good luck

 

[sjl]

Because we don't have copy storage pools, we cannot use any DRM command (based on what I read).

This is correct: DRM commands work on copy pool volumes and database backup volumes, not on primary pool volumes.

Why do you not have a copy pool? A colleague of mine when I was working at IBM had a very succinct way of putting it: if you don't have a copy pool, it's obviously not worth backing up in the first place. You're exposing yourself to a whole slew of risks that are mitigated significantly (although not eliminated completely) by duplicating data to a second set of tapes.

So I take a look at the "move media" command, which seems interesting to me. Have you already use that command before?

I worked with a client (again, while I was at IBM) that had some data duplicated, some not; for the data that wasn't duplicated, they used MOVE MEDIA to send the tapes offsite.

It was, bluntly, a right royal pain in the backside. You lose on reclamation: TSM can't consolidate data onto fewer volumes if it doesn't have access to a readable copy of the data. (so you buy way more tapes than you need, which can be a significant avoidable expense.) You lose on operational issues: if TSM needs a given tape, it gives you (from memory) one hour to get it back into the library, after which the volume is marked unavailable and the job that wanted the data fails. You lose on race conditions - if you do a move media and it takes a while for the tape to be ejected, there can be all sorts of issues with backup jobs trying to access the tape.

I strongly recommend that you get copy pools up and running, duplicate your data, and send the copy pool volumes offsite instead of mucking around trying to shoehorn TSM into doing a job that runs counter to its design philosophies. Doing anything else is inviting a world of pain. You don't want to go there - trust me on this.

 

[sandeepkontham]

"move media" is the best way to move primary stgpool volumes out of library for free slots.

CMD: move media volume_name stgpool=stgpool_name ovflocation=offsite_locationname

TSM database tracks and keep records of all volumes moved out by above command, you can track the tape with ovflocation details.

During restore you get messages about the tape and the location, you can bring back and checkin the tape for a successful restore.

TSM is not reliable without offsite tapes............no disaster support and you cannot recover from bad tape issue

 

[MKozachkov]

similar situation. please help

what's the command to check in tapes from the overflow location ?