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