Can anyone tell me what is in PMR 62476,033,000? Apparently IBM believes that
someone following the steps in that PMR caused the lose.
Thanks,
Ray
On May 30, 2012, at 7:39 AM, Ray Carlson wrote:
> It was a brand new 2008 Server with a 6.3.0 install, which has been upgraded
> to 6.3.1.1 because of other problems. Then the database was converted from a
> 5.5 version.
> It started with completely empty and new disk storage pools. Then data was
> moved from tape back to the disks. Finally, Deduplication and Replication
> were implemented. It had been running for several months before the problem
> arose. I don't know if it is old data or fresh data since I haven't been
> able to identify exactly which file is involved. Unfortunately I do not have
> the call reference number since that part is being handled by an outside
> company. I have also not had the opportunity attempt a restore using the DR
> tapes since that would involve recalling multiple tapes from an offsite
> company. Basically, this is stopping some of my Generate backupsets and it
> required that I do a disk to disk copy of the data I was trying to restore.
> I still had the original data on the server and was simply using restore to
> move it to a replacement server. Thankfully, I haven't lost my original data
> on the servers, just the ability to restore it from tsm if it was lost.
> Ray
> On May 30, 2012, at 4:09 AM, DeGroat, Steve wrote:
>
>> Same here, we are about to go "live" on a new 6.3.1 server expecting client
>> and server side deduplication. Any additional information about the
>> environment would be helpful.
>>
>> Steve DeGroat
>> Storage Manager
>> ITS Production Services
>> Yale University
>> 203.436.4540
>>
>> "If you build it, they will come."
>>
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf
>> Of Steven Langdale
>> Sent: Wednesday, May 30, 2012 3:24 AM
>> To: ADSM-L AT vm.marist DOT edu
>> Subject: Re: [ADSM-L] DATA Corruption using Deduplication in TSM 6.3.1.1
>> WARNING
>>
>> Ray, on top of what Remco posted, woudl you also post your call ref?
>>
>> I'm about to implement a new 6.3 environ using dedupe so would like to press
>> our IBM technical rep on the issue. You never know, with a few people
>> asking about it, it mya get fixed quicker.
>>
>> Best of luck with your issue though!
>>
>> Steven
>>
>> On 30 May 2012 07:08, Remco Post <r.post AT plcs DOT nl> wrote:
>>
>>> Hi Ray,
>>>
>>> Thanks for the warning.
>>>
>>> I was wondering if you could tell us a bit more about this TSM server.
>>> Is it a converted 5.5 server? At which 6.x level did you start using
>>> TSM version 6 for this server, 6.1, 6.2 or 6.3? Do the errors occur
>>> with any particular kind of data? Is it 'old' data, or fresh data
>>> recently written to TSM? Are you able to restore the files from
>>> copypool if this error occurs?
>>>
>>> On 29 mei 2012, at 20:46, Ray Carlson wrote:
>>>
>>>> Or as IBM called it, "Orphaned deduplicate references".
>>>>
>>>> We are running TSM 6.3.1.1 on a Windows 2008 Server, and using the
>>> Identify command to do deduplication on the Server, not the client.
>>>>
>>>> Interestingly, everything seemed to be mostly working. We had a few
>>> volumes that would not be reclaimed or moved because it said the
>>> deduplicated data had not been backed up to the copy pool, but that
>>> was jut an annoyance.
>>>>
>>>> Then we discovered that we could not do restores of various servers.
>>> The error we got was:
>>>> "05/21/2012 20:52:45 ANR9999D_2547000324 bfRtrv(bfrtrv.c:1161)
>>> Thread<129>: Error 9999 obtaining deduplication information for object
>>> 254560532 in super bitfile 664355697 in pool 7 (SESSION: 8235, PROCESS:
>>> 375)".
>>>>
>>>> A Severity 1 trouble ticket was opened with IBM back on 5/21 and
>>>> various
>>> information was gathered and provided to IBM. So far IBM has not been
>>> able to identify the root cause or provide a fix. They have
>>> transferred the ticket to the Development team.
>>>>
>>>> So here I sit, not knowing which servers, if any, I could restore if
>>> needed. Unfortunately, most operations appear to be fine and report
>>> Success. Only when I try to do a Generate Backupset, or do a Restore,
>>> do I discover that there is a problem and the job fails. Also, it
>>> doesn't just skip the file/files that it can't restore and restore
>>> everything else, it simply stops the restore and says it failed.
>>>>
>>>> I'm wondering how many other people are in the same situation, but
>>>> do
>>> not realize it.
>>>>
>>>> BEWARE Deduplication
>>>>
>>>> Ray Carlson
>>>
>>> --
>>> Met vriendelijke groeten/Kind Regards,
>>>
>>> Remco Post
>>> r.post AT plcs DOT nl
>>> +31 6 248 21 622
>>>
>
|
