ldmwndletsm
ADSM.ORG Senior Member
- Joined
- Oct 30, 2019
- Messages
- 232
- Reaction score
- 5
- Points
- 0
If you have a bad primary pool tape (a volume audit reports lots of errors on the tape and bad /damaged files), and you then run a 'restore volume' to create a new primary pool tape from a good copy pool volume then what happens if you later audit any of the tapes wherein one or more files on the bad tape spanned to/from?
I have hunted around everywhere in the IBM documentation, and I could find nothing on this other than the 'skippartial' parameter for audit volume, but this tells me nothing about the restore. Let's says the bad tape is B0080, and there was one file that spanned from tape B0077 and one file that spanned to tape B0079. Seems to me that those pieces/parts would still be occupying physical space on those other two tapes, and even if TSM forgets about them and knows only about the "new" primary pool tape (call it B0090), following the restore, then if you later audited those other two tapes, would it not still find those files and complain that they're not in the database? That information would have been removed following the restore, right? If so, how would you reconcile the output from the audit? How would you know it was or was not expected? Is this something to be concerned about?
Maybe my understanding is all wrong here? Perhaps the restore would not affect those other pieces and only rebuilds what is physically on the bad tape, not the pieces that span to/from? I was thinking not, and that a 'q content volume' would no longer report those files on those other tapes, only the new tape(s), but I've not tried it. Wanted to inquire first, before running the 'restore volume'. Thanks.
I have hunted around everywhere in the IBM documentation, and I could find nothing on this other than the 'skippartial' parameter for audit volume, but this tells me nothing about the restore. Let's says the bad tape is B0080, and there was one file that spanned from tape B0077 and one file that spanned to tape B0079. Seems to me that those pieces/parts would still be occupying physical space on those other two tapes, and even if TSM forgets about them and knows only about the "new" primary pool tape (call it B0090), following the restore, then if you later audited those other two tapes, would it not still find those files and complain that they're not in the database? That information would have been removed following the restore, right? If so, how would you reconcile the output from the audit? How would you know it was or was not expected? Is this something to be concerned about?
Maybe my understanding is all wrong here? Perhaps the restore would not affect those other pieces and only rebuilds what is physically on the bad tape, not the pieces that span to/from? I was thinking not, and that a 'q content volume' would no longer report those files on those other tapes, only the new tape(s), but I've not tried it. Wanted to inquire first, before running the 'restore volume'. Thanks.