Veritas-bu

[Veritas-bu] NBU database problem/bad image header

2000-10-19 11:54:21
Subject: [Veritas-bu] NBU database problem/bad image header
From: Rob Worman rob AT colltech DOT com
Date: Thu, 19 Oct 2000 08:54:21 -0700
Ryan-

the bad news:
As you have probably already concluded, you have database corruption - it 
happened because your NBU database filesystem filled up while NBU was trying to 
write catalog data about ongoing backups.  It even appears as if this 
corruption is preventing ongoing backups from working?

the good news:
It's not hard to fix, it just might take awhile to track down the corrupted 
files.

Do you back up your master server as part of a normal NBU class?  If so, the 
recovery is may be a bit simpler for you.

First off, you need to identify the exact files that are corrupt.  How 
comfortable are you with the way the NBU image database is organized? A quick 
primer...

Basically for any given backup there are 2 text files that get created - the 
big nasty file list:

    /usr/openv/netbackup/db/images/$CLIENT/$CLASS_$DATE_$TYPE.f

      where $CLIENT is the client name as defined at backup time
            $CLASS is the class name
            $DATE is the "epoch" date the backup went active
            $TYPE is the backup type (FULL,INCR,CINC)

        this file is a list of every single file that was backed up by 
        this particular backup job.

and then the backup "image header" file:

    /usr/openv/netbackup/db/images/$CLIENT/$CLASS_$DATE_$TYPE
        which is a much smaller file that lists all the
        important data about the backup image.


so when you have a corrupt NBU catalog (as evidenced by the types of error 
messages you see below), it really just means that for one or more backup 
images, one or both of the above files has been hosed.

So fixing the corruption means tracking down the hosed files and restoring them 
(if possible) or deleting them (and if indeed your current corruption is 
causing problems in getting backups to run, then I'd first get those corrupted 
files out of your images DB, get your backups to run, and then tackle the 
restoration process)

does this make sense?

rob

>We are using DLT 7000 drive, but the errors below are related to the
>images in the NBU database.  Its been two days since this happened now,
>and the two classes affected with this problem haven't backed up
>anything in their incrementals, although I know they have new data in
>them--but they return a status code 0.  As of this morning, I'm getting
>the same errors as my previous post.
>
>Thanks,
>
>RCA
>
>
>"Humphries; Douglas" wrote:
>> 
>>  What type of drives are you using?  We had problems doing restores from
>> backups which seemed to have run successfully but got bad image header
>> errors when doing the restores.  We are using STK9840 drives.  I never had
>> this problem with DLT7k drives.  I got zero help from either Veritas or STK
>> on this issue.
>> 
>> -----Original Message-----
>> From: McMurphy, Tim
>> To: Veritas NBU
>> Sent: 10/18/00 5:29 PM
>> Subject: RE: [Veritas-bu] NBU database problem/bad image header
>> 
>> How is your db backup? You may have to use it.
>> 
>> -----Original Message-----
>> From: RYAN C. ANDERSON [mailto:ryan_anderson AT udlp DOT com]
>> Sent: Wednesday, October 18, 2000 3:19 PM
>> To: Veritas NBU
>> Subject: [Veritas-bu] NBU database problem/bad image header
>> 
>> I have a problem relating to the previous thread about the NBU
>> database.  Below is the output of bpadm --> reports --> problems.
>> Unbeknownst to me, an admin had tried a restore on a very large server
>> with many small files yesterday.  He had chosen a large range of dates
>> and the filesystem where the NBU db filled up.  Its otherwise just fine
>> being in a more compressed state.  We recompressed the files, but now,
>> I've gotten these errors below and am not sure what to make of it.  I
>> searched through the mailing list archives and NBU newsgroup on this
>> issue, and didn't find too much, but someone had suggested using '#
>> bpdbm -consistency' might fix the problem.
>> 
>> The files its cacking on are all 0 length and were created at the time
>> the filesystem filled up.  Any thoughts?
>> 
>> Thanks,
>> 
>> RCA
>> 
>> ===================================================================
>> 
>> info.../usr/openv/netbackup/db/images/faithful/0932000000/tyr_therest_09
>> 3221
>> 6789_FULL
>> 10/17/00 23:59:40 faithful -  cannot get image
>> 
>> info.../usr/openv/netbackup/db/images/faithful/0971000000/heimdall_P_int
>> eg_0
>> 971500172_FULL
>> 10/17/00 23:59:40 faithful -  cannot get image
>> 
>> info.../usr/openv/netbackup/db/images/faithful/0971000000/heimdall_P_int
>> eg_0
>> 971500172_FULL
>> 10/17/00 23:59:43 faithful -  cannot get image
>> 
>> info.../usr/openv/netbackup/db/images/faithful/0932000000/tyr_therest_09
>> 3221
>> 6789_FULL
>> 10/18/00 03:16:01 faithful -  Bad image header:
>> tyr_therest_0932216789_FULL
>> 10/18/00 03:16:06 faithful -  Bad image header:
>> heimdall_P_integ_0971500172_FULL
>> 10/18/00 05:13:17 faithful -  Bad image header:
>> tyr_therest_0932216789_FULL
>> 10/18/00 05:13:23 faithful -  Bad image header:
>> heimdall_P_integ_0971500172_FULL
>> 10/18/00 10:24:45 faithful -  Bad image info in
>> 
>> /usr/openv/netbackup/db/images/faithful/0971000000/heimdall_P_integ_0971
>> 5001
>> 72_FULL
>> 
>> Ryan C. Anderson        |   United Defense L.P.
>> Unix Administrator      |   763.572.6684 (desk)
>> ryan_anderson AT udlp DOT com  |   612.235.9936 (pager)
>_______________________________________________
>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>