Did the catalog backup work for you after removing the policies from 
critical policy list by any chance?  Or..?

On Mon, 9 Jun 2008, Justin Piszcz wrote:

> I opened a few, I do not/cannot find the latest one at the moment..
>
> 240-639-842 # was the beginning when I asked what was wrong/why was it 
> failing, they were not sure. They said to increase the timeouts/etc that did 
> not help.
>
> Found it:
>
> Case # 320-101-338
> Closed
> NetBackup Enterprise Server 6.0 MP5
> Summary
> There is a bug I would like to report on NetBackup 6.0MP4+5.
>
> Detail :
>
>
> JUSTIN PISZCZ
>
>
> There is a bug I would like to report on NetBackup 6.0MP4+5, I have found a 
> work-around but this bug needs to be addressed.
>
> I have found the root cause of this and need to explain what was wrong.
> 6. First it was LOC1 now LOC2 is also having problems sometimes backing up 
> the catalog to tape. The error we get is shown below:
> a. 1: (41) network connection timed out
> b. 2: (0) the requested operation was successfully completed
> c. Fortunately, it did retry and succeed, but it should not be failing the 
> Catalog Backups at all.
>
>
> I reported it but it was in the 'researching' status for a week or so and 
> then it was pending close so from the engineer I think?  / In any event it 
> was closed at the end.
>
> Summary :
> THOMAS
>
> Plan of Action
>
> Detail :
> ISSUE: There is a bug I would like to report on NetBackup 6.0MP4+5.
> STATUS: researching
> ACTION: researching
> NEXT CUSTOMER CONTACT: April 9th, 2008
>
> Hope this helps.
>
> Justin.
>
> On Mon, 9 Jun 2008, Mark Glazerman wrote:
>
>> Justin,
>> 
>> Sorry for the name mixup.  Would you happen to have the case number 
>> available from when you contacted Symantec about this issue ?  I'd like to 
>> add it to my case notes as a reference to see if support can use it to 
>> definitively link those critical policies to the problem.
>> 
>> Thanks
>> 
>> Mark Glazerman
>> Desk: 314-889-8282
>> Cell: 618-520-3401
>> ? please don't print this e-mail unless you really need to
>> 
>> 
>> -----Original Message-----
>> From: Justin Piszcz [mailto:jpiszcz AT lucidpixels DOT com]
>> Sent: Monday, June 09, 2008 2:46 PM
>> To: Mark Glazerman
>> Cc: veritas-bu AT mailman.eng.auburn DOT edu
>> Subject: RE: [Veritas-bu] Catalog backup exiting with Status code 2 - 
>> unable to verify nbdb database
>> 
>> There is no Jason here. <snicker>
>> 
>> I was getting them 75-100% of all catalog backups once the critical
>> policies had backup (clients) in them with too many files in them
>> (millions), removing the critical policies solved the bug.
>> 
>> Justin.
>> 
>> On Mon, 9 Jun 2008, Mark Glazerman wrote:
>> 
>>> Jason,
>>> 
>>> Thanks for your explanation.  Just out of curiosity, how often were you 
>>> getting the 2's ?  We've only had them twice since upgrading to 6.5.1 
>>> (about a month ago) so it wasn't like we had constant problems.  However, 
>>> with the catalog being such a critical component of the NBU environment, 
>>> we couldn't go on hoping that they wouldn't fail again.
>>> 
>>> Thanks again... gotta love how folks like you can pinpoint a problem 
>>> quicker than Veritas themselves !!
>>> 
>>> Mark Glazerman
>>> Desk: 314-889-8282
>>> Cell: 618-520-3401
>>> ? please don't print this e-mail unless you really need to
>>> 
>>> 
>>> -----Original Message-----
>>> From: Justin Piszcz [mailto:jpiszcz AT lucidpixels DOT com]
>>> Sent: Monday, June 09, 2008 2:35 PM
>>> To: Mark Glazerman
>>> Cc: veritas-bu AT mailman.eng.auburn DOT edu
>>> Subject: RE: [Veritas-bu] Catalog backup exiting with Status code 2 - 
>>> unable to verify nbdb database
>>> 
>>> Remove them.
>>> They were the cause of my error 2s. I already reported it to Symantec.
>>> 
>>> I may be corrected here because it is a little confusing to me as well,
>>> but.. From what I understand if you are recovering from a LARGE catalog
>>> the clients in the critical policy list will be able to perform restores
>>> before the full recovery of the catalog is complete (I believe)..
>>> 
>>> I have performed a FULL backup and recovery w/out critical policies (in
>>> 5.x they did not exist) and also two production environments with 6.0MP6
>>> with no issues, they are not needed for catalog recovery.
>>> 
>>> Disable your current policy, copy it and delete the critical policies and
>>> retry it for kicks? :)
>>> 
>>> Justin.
>>> 
>>> 
>>> On Mon, 9 Jun 2008, Mark Glazerman wrote:
>>> 
>>>> Justin,
>>>> 
>>>> We have 7 policies listed in the critical policies list.  They are the 
>>>> policies that back up out tier one data.  I have to admit that I'm not 
>>>> really sure why we specify them but could you tell me why having them / 
>>>> removing them would make any difference ?
>>>> 
>>>> Thanks for your prompt reply.
>>>> 
>>>> Mark Glazerman
>>>> Desk: 314-889-8282
>>>> Cell: 618-520-3401
>>>> ? please don't print this e-mail unless you really need to
>>>> 
>>>> -----Original Message-----
>>>> From: Justin Piszcz [mailto:jpiszcz AT lucidpixels DOT com]
>>>> Sent: Monday, June 09, 2008 2:29 PM
>>>> To: Mark Glazerman
>>>> Cc: veritas-bu AT mailman.eng.auburn DOT edu
>>>> Subject: Re: [Veritas-bu] Catalog backup exiting with Status code 2 - 
>>>> unable to verify nbdb database
>>>> 
>>>> Only an idea-- do you use critical policies in your Catalog backup 
>>>> policy?
>>>> If so, delete them and try again.
>>>> 
>>>> On Mon, 9 Jun 2008, Mark Glazerman wrote:
>>>> 
>>>>> I've had a ticket open with Symantec for over a week now regarding our
>>>>> catalog backups randomly failing with a status code 2.  We are running
>>>>> NBU 6.5.1 on Solaris 10 x86.
>>>>> 
>>>> 
>>> 
>> 
>
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu