Tape verify?

[ryan147]

Hello!



As TSM operator I am sure you have encountered the following situation.

We are encountering some read errors on our LTO Unit now and then causing the access mode of the tapes to be set as "unavailable". Our normal procedure to gain access to the tapes again is as follows:



- set access mode to readonly

- move media to storagepool



The "unaccessible" tape will be used again as scratch.



However, this procedure may take a lot of time in case the tape has a lot of stored data on it. My question is therefore as follows: Does TSM have some kind of (hidden) tape verify function to check the validty of the data on it? That way we do not have to move the media of the tape and perhaps increase the time needed to ensure validity.



Your comments are welcome,



Ryan

 

[heada]

Ryan,



Look into the command 'audit volume' It compares what is on tape to what is in the TSM database. There is a fix option on it as well.



-Aaron

 

[AndyRH]

We take a different approach with our 3590 tapes. If a tape becomes unavailable it is usally because of a tape drive problem. We make the tape read/write and take no other action. If a tape becomes readonly due to a tape error, then we move the data off the tape and remove the tape from use.



Just something to think about.



Andy

 

[ryan147]

<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>Ryan,



Look into the command 'audit volume' It compares what is on tape to what is in the TSM database. There is a fix option on it as well.



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



Yes the "audit vol" command is the one I was looking for. Sometimes errors are not only caused by faulty tape but it can also be due to dirty drives. Good thing there is this command.



Anyhow, there is another situation that has come up. We now got a tape that has been set to "unavailable" in our offside pool. I want to use a scratch tape that contains the exact set of data as the one in the offside pool, so that the offside tape can be made scratch or we might just take it out ot the loop. How can I do that? I'm also open to other options.



TIA, Ryan

 

[heada]

Ryan,



The simle way is to just delete the copy pool volume and let a new copy be created when you run "backup stgpool" for the primary pool. The only drawback to this is, if the primary version is corrupted or damaged or something, then it won't be able to make a good second copy.



The other option that I can think of is "move data". You'll need to recall the copy volume and tell tsm that it's available.



(recall volume and checkin to library)

update vol (vol_num) access=readonly

move data (vol_num) stgpool=(copypool) reconstruct=yes



That should recreate the volume from the original volume and make the original volume scratch again.



-Aaron

 

[sergio.morales]

Hi guys . . . what if the tape you're attempting to rebuild is broken? I have an offsite tape that looks like it was dropped . . . I don't know how it got this was but it's split down one side and is illegible by the tape drive. If I delete this volume, will the copy stgpool make me a "new" copy of the same data that is in it?



Thanks!!



sERGE

 

[heada]

It's my understanding that the database knows what data has been copied and what hasn't. If you delete the copy, the database will no longer have copy information for that tape and will make a new copy the next time you issue a 'backup stgpool' command.



I have used this procedure several times (as a quick reclaimation procedure) and it seems to work.



Since your data might be more important then mine, you might want to query the contents of the broken volume and verify that the primary copy of that data is still valid.



(q con {copy-vol})

perform restore of files from primary pool to temp server/storage

del vol {copy-vol}

backup stgpool {primary pool} {copy pool}



One thing to be VERY careful of....do NOT delete the primary volume as it will delete the copy volume also.



-Aaron