I have been sort of following this thread, This is not a very technical description, and my understanding of your problem.
A: you restored your DB. B: you audited your on-site tapes with the fix option C: you try to reclaim the off-site tapes and you get "magic numbers" What I have seen on my site is that once I have restored the DB to a point in time some of the data held in the stgpools; both disk and tape is unknown to TSM. You receive a magic number on a tape when TSM runs across this data either reading or writing, you are correct in saying an audit/fix on the tape should solve this issue, but it does sound like the next option for you to try is an audit/fix on the database. Depending on the size it should be completed in 24hrs. Also you mention that this is happening when you try to reclaim the copypool tapes, what is happening when you reclaim or move tapepool tapes. Also when you try to restore a volume, have you looked at restoring the stgpool with the view only option to see what that thinks of your current state. I never have the time to run audit/fix on my tapes pools, I have to many tapes, so normally I run it on the tapes as the error appears. Anyway not much help I know. My servers are TSM 4.1.4.1 on NT2000 and NT4.0 using STK9710 silo's. Anthony. -----Original Message----- From: John Naylor [mailto:[EMAIL PROTECTED]] Sent: Thursday, 15 November 2001 3:42 AM To: [EMAIL PROTECTED] Subject: Re: Antwort: Re: ANR9999D with a strange message Hi Wanda, This sounds like one for support. I don't know what your server version is, but is at a level which supports the command SET CONTEXTMESSAGING ON This is supposed to give you a bit more background detail to the ANR9999D "Prather, Wanda" <[EMAIL PROTECTED]> on 11/13/2001 10:30:22 PM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: John Naylor/HAV/SSE) Subject: Re: Antwort: Re: ANR9999D with a strange message Yep. I've done audit on EVERY volume in the library. More than once. Also, since the primary pool is collocated and the offsite pool is not, it is frequently impossible to tell WHICH primary volume needs to be restored. You see the error on the reclaim of the copy pool tapes; since we normally hit many tapes in a reclaim cycle, you find these errors in the log and can't really tell which primary pool tape is the culprit. And when I can tell, the RESTORE VOLUME doesn't always fix it, and I end up deleting the remainin few files on teh copy pool tape, on the assumption that TSM will pick them up again the next time a do BACKUP STGPOOL. So far, I"m baffled. I see maybe 50 files a week with this error, while millions have gone through reclaim. And it's only the copy pool tapes that seem to have a problem, so I haven't been scared enough by it yet to shut down and audit the DB. I"m thinking of doing that over the New Year holiday. -----Original Message----- From: Bill Colwell [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 5:05 PM To: [EMAIL PROTECTED] Subject: Re: Antwort: Re: ANR9999D with a strange message Have you done 'audit volume fix=yes'? If these errors occur during offsite reclaim, then the problem is on the primary tapes. I have had problems like this a long time ago, nothing recent (knock on wood). I would do a move data on the primary volume until it quit with the error, then audit the volume, fix=yes, then do move data again until only bad files were on the tape, then do a restore volume. I never, ever had to do a discarddata on a primary volume, restore volume has always worked. -- -------------------------- Bill Colwell C. S. Draper Lab Cambridge, Ma. [EMAIL PROTECTED] -------------------------- In <[EMAIL PROTECTED]>, on 11/13/01 at 05:04 PM, "Prather, Wanda" <[EMAIL PROTECTED]> said: >The problem is here we don't have any idea what is being deleted if we >delete it. >These errors occur on RECLAIMS for COPY POOL tapes. So you may be getting >errors on stuff that is months old, and the client can't back it up again. >If I could look at the contents of the tapes that won't reclaim and tell >whether there is a good copy in the primary pool, or a later backup copy, >that would be fine. But running contents on the tape won't tell you that. >And of course the big issue is WHY are we getting these errors? they are >getting scary, as they shouldn't be there at all. They are not the result >of physical I/O errors on any media. >-----Original Message----- >From: Mark Stapleton [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, November 13, 2001 12:49 PM >To: [EMAIL PROTECTED] >Subject: Re: Antwort: Re: ANR9999D with a strange message >On Mon, 12 Nov 2001 09:53:51 +0100, it was written: >>RESTORE VOLUME did not fix anything here. We are back at those >> >>ANR9999D ssrecons.c(2342): Actual: Magic=1C9F3202, >>SrvId=-61862846, SegGroupId=3512872581838733325, >>SeqNum=805461472, converted=T. >> >>Messages. It seems that the data already were damaged when the BACKUP >>STORAGEPOOL command run. >>I am wondering now in two ways : >> >>2. What should we do next ? Do we have other possibilites than to do a >DELETE >>VOLUME xxx DISCARDDATA=YES ? >It's not that bad a deal to delete a volume. When the clients do their >first backup after the volume deletion, they will just back up the >missing files again. Your biggest window of vulnerability will be a >few hours. >-- >Mark Stapleton ([EMAIL PROTECTED]) ********************************************************************** The information in this E-Mail is confidential and may be legally privileged. It may not represent the views of Scottish and Southern Energy plc. It is intended solely for the addressees. Access to this E-Mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any unauthorised recipient should advise the sender immediately of the error in transmission. Scottish Hydro-Electric, Southern Electric, SWALEC and S+S are trading names of the Scottish and Southern Energy Group. ********************************************************************** Notice: The information contained in this e-mail message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this e-mail is unauthorised. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete all copies of this transmission together with any attachments.