"Destroyed" Primary Vol Restored, now what?

[GregE]

I've restored a primary tape vol I had marked destroyed. Now I'd like to delete the destroyed volume and reuse it (it's not actually bad, I had other reasons for having to mark it destroyed).

If I run a DEL VOL it won't delete if I use discarddata=no. But if I use discarddata=yes will TSM then delete the data from all copypool volumes too? Or does TSM know that this destroyed volume has been restored? Does TSM only discard data from this one and not propagate the data deletion to copypool?

 

[GregE]

You're right. Now that I look at documentation, the volume should have been automatically deleted.

I just ran it again to see what's what...

ANR2110I RESTORE VOLUME started as process 721.
ANR1235I Restore process 721 ended for volumes in storage pool DB_TPOOL.
ANR0985I Process 721 for RESTORE VOLUME running in the BACKGROUND completed
with completion state SUCCESS at 01:49:24 PM.
ANR1240I Restore of volumes in primary storage pool DB_TPOOL has ended. Files
Restored: 0, Bytes Restored: 0, Unreadable Files: 0, Unreadable Bytes: 0.
ANR1256W Volume TSM177L3 contains files that could not be restored.

So if it contains files that can't be restored, what do I do with it? I restored it a couple days ago and it restored all that it could. I'm afraid that if I delete and discard, the discarding of data will discard from copy pools too. Maybe that's not an issue? Maybe no more matching data exists in copy pool, and that's the reason for the warning "ANR1256W Volume TSM177L3 contains files that could not be restored." ??

 

[GregE]

Yeah, if you force delete/discard that tape, you will definitely lose any copies of those files that exist in your copystgpool. Now, you determined what tapes were needed to perform the restore operation. Are all of those tapes in a state that allows them to be read? Are they marked READO, etc?

Also, is it possible that the contents of your copystgpool have been jostled about a bit since you originally determined what tapes were needed? I mean, if you figured out what tapes you needed on Monday, is it possible that Tuesday's reclamation processes changed the contents of the tapes? Perhaps reclamation moved the files you need from one tape to another?

I don't think I have any more choices but to just delete that primary vol and discard the data. The "restore vol" I just issued with a preview shows me that there are files that cannot be restored, so it's a new command with up-to-date results. I've had some tape issues lately since my upgrade to server 5.4.3, with some copy pool volumes having had to be recreated from primary. It's quite possible that something got lost in that fiasco and the copy pool doesn't contain info on the destroyed primary.

 

[GregE]

Just bringing this back up for anyone who has some thoughts. I have several primary stg volumes I've restored. If they fully restore, TSM would then delete them as designed, but as stated earlier, it says some files cannot be restored. So now that TSM is done doing all that it can do, what do I do with these primary stg volumes that TSM should have been deleted?

Still working with IBM since my 5.4.3 upgrade, as tapes are intermittently not able to have their internal labels read. Very random. Not good!

 

[BBB]

1. Does "q content <volname>" show there's any files on the volume?
2. Run "audit vol <volname>" on the destroyed volume. This may cause actually fix your problem in that the remaining issue is an audit one. It may not even need to mount the tape to fix it.
3. Failing that you can run del vol <volname> discarddata=yes

 

[GregE]

Thanks BBB. Q CONTENT shows it contains files. I ran an audit vol and result was the same. It can't load the tape properly to even do anything.....

ANR8355E I/O error reading label for volume TSM177L3 in drive DR_6C14
(/dev/rmt/3st).

Very annoying. 5.3.2 server was running fine, and since 5.4.3 (a month now) I've been having to spend my time picking thru things everday as tapes become unrecognizable by TSM. Finally got some trace information into IBM's hands and am awaiting the analysis. I'll hold off on discarding data until speaking again with IBM. These are primary stg vols.

 

[BBB]

Are all your copypool volumes available and in read or readwrite state? I take it these files do exist on copypool vols - check with q contents <vol> copied=no I think the syntax is. What appears in your actlog (q act) when you do a restore vol? There should be more details in there about why it couldn't restore the other files - that's the way it normally happens.

 

[GregE]

All copypool vols are available and in read/read-write state. I've just checked contents of one of the primary volumes, using copied=no, and yes there are files that were not copied. Actlog shows only what I posted earlier. I wish it showed more but it doesn't.

What is happening, and the reason we've turned on tracing (periodically, as it is a very fast growing text file) at IBM's request, is that intermittenly a volume will be written and as it dismounts the error occurs:

ANR8355E I/O error reading label for volume TSM177L3 in drive DR_6C14 (/dev/rmt/3st). (SESSION: 56515, PROCESS: 1375)

At this point, this volume is not useable and if it's a copy pool vol, I delete it and the data gets copied again. If it's a primary volume, it has to be restored. Now that I think about it, this happens on migration and also on copy, so I think what's happening is that when the primary vol migration writing is done and the error occurs as the tape dismounts, that data never was written to copy pool, so if the problem primary pool vol has other previously copied data on it, that data is available in copy pool, to restore, but any new data never makes it to copy pool and is not restorable.

Hopefully IBM can figure this one out. I have non-restorable data and no confidence in my stored data at this point until it's resolved.