Veritas-bu

Re: [Veritas-bu] Corrupt header files

2009-04-27 15:54:16
Subject: Re: [Veritas-bu] Corrupt header files
From: "Ron Jack (Systems Network)" <rjack AT nando DOT com>
To: "Conner, Neil" <neil AT mbari DOT org>
Date: Mon, 27 Apr 2009 15:04:21 -0400
6.0 MP4 on Solaris 9. 1 hit out of 7700 "FULLS".

hth.


Conner, Neil wrote:
> Bob,
> Thanks for the confirmation.  I would have been very surprised if there was
> something that unique about my installation.
> 
> Maybe it's nothing to be concerned but I'm not willing to just assume that.
> I've asked to have my case escalated and I'll let you know what I find out.
> 
> Neil
> 
> 
> 
> On 4/24/09 12:49 PM, "bob944" <bob944 AT attglobal DOT net> wrote:
> 
>>> ------ Forwarded Message
>>> From: "Conner, Neil" <neil AT mbari DOT org>
>>> Date: Thu, 23 Apr 2009 16:55:19 -0700
>>> To: Veritas List <veritas-bu AT mailman.eng.auburn DOT edu>
>>> Conversation: Corrupt header files
>>> Subject: [Veritas-bu] Corrupt header files
>>>
>>> Netbackup 6.0 MP5 on Solaris 10.
>>>
>>> I was working with support and they had me edit some header files
>>> and I
>>> happened to stumble upon one that had some corruption in it: I got
>>> the
>>> following error when I opened it with vi:
>>>
>>> "client_1212199228_FULL" [Incomplete last line]
>>>
>>> I found that an extra line of white space had been tacked on at
>>> the bottom
>>> of the file, but it was missing the EOL character.  So I wrote a
>>> script to
>>> look for more occurrences and I was shocked to find that over a
>>> third of my
>>> header files have this extra garbage line in them, and they are
>>> still being
>>> created.  I?ve got over 13,000 corrupt header files for full
>>> backups alone.
>>>
>>> Restores from the corrupt header files are successful, with or
>>> without the
>>> extra line of garbage (which is why it has gone undetected until
>>> now).  At
>>> this point, support is telling me to either live with it or fix
>>> all the
>>> corrupt files, but so far at least, they have not tried to address
>>> the root
>>> cause and I?m not satisfied with that.  So I?m wondering if anyone
>>> else has
>>> a similar issue.
>>>
>>> Here is the script (it only samples full backups so it runs
>>> faster).  Update
>>> the path to the image database if necessary and you can run it
>>> from
>>> anywhere.
>>>
>>> #!/bin/ksh
>>> #
>>> # Check for corrupt header files:
>>> # These will have white space at the end of a line.
>>> # grep ?l (ell) produces a list of files instead of a bunch of
>>> white space.
>>> #
>>> ImageDB=/usr/openv/netbackup/db/images
>>>
>>> for DIR in `ls -R | find $ImageDB -type d`
>>> do
>>>     grep -l " \$" $DIR/*FULL 2>/dev/null
>>> done
>>>
>>> I?d be grateful if some of you would run this against your
>>> catalog.  If you
>>> get any hits, try to edit one of the files and see if you get an
>>> ?Incomplete
>>> last line? error.
>> Neil - I can confirm the extra spaces.  In a test domain, I found
>> 10% of metadata files ended with a line of one or three spaces; the
>> last good line being either VM_TYPE or LAST_BIRTHTIME which always
>> have an even number of characters.  I checked incrementals and they
>> have the same thing.
>>
>> Opening them with vi, I do get an "incomplete last line,"  When I
>> "G" I'll be on a line comprised of one or three spaces.
>>
>> I don't see an obvious pattern.  I see it on hot catalog, standard
>> and windows-nt policies, in diff and full schedules.  I have
>> instances from August,08 through this month (and I don't have any
>> older backups here so August may be only a limitation on my data.
>> All backups were done on either 6.5.1 or 6.5.3.1.
>>
>>
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

<Prev in Thread] Current Thread [Next in Thread>