Veritas-bu

[Veritas-bu] Problems with available_media and state DBBACKUP

2001-05-16 11:43:25
Subject: [Veritas-bu] Problems with available_media and state DBBACKUP
From: wyatt.song AT veritas DOT com (Wyatt Song)
Date: Thu, 17 May 2001 01:43:25 +1000
Duane,

I don't know if the problem you are facing has a direct relationship with
losing drives, but it definitely appears to me like you have lost media
server's database (includes media database $NBU/db/media/mediaDB) on the
media servers.

I know the symptom you are talking about on available_media report, a while
ago i did a test in the lab proving what's in mediaDB on the media servers
and what's the consequences of lossing mediaDB.  (please see attached below
lab notes)

Now you would be able to perform restors, as the necessary information for
the restore are kept in the image headerfile and volDB is intact.  But it is
very painful to rectify the problem once you lost the mediaDB (that's one of
the reason why one needs to backup media server's database in their catalog
backup).  This is the one thing i didn't do in the lab, There is no easy way
out as far as i can see, don't see a problem import the tape, but you may
have to expire it before import.  You can also try to move it to other media
servers, use bpmedia -movedb -newserver hostname [-oldserver hostname].  I'm
interested in the result, please let me know.

Wyatt

=============================================
Is mediaDB redundant when volDB is centrally located on the master? What
information does mediaDB contains and what's the implication of losing
mediaDB?  

Solution:

About media database (mediaDB on each media server as opposed to volume
database volDB), customer asks the questioning why one needs to backup
database on media servers through catalog backup, when successful restores
can be performed after the mediaDB on the media server is lost.

Restores from previously backup CAN be done even without the mediaDB on the
media server.  So is mediaDB redundant when volDB is centrally located on
the master?  What information does mediaDB contains and what's the
implication of losing mediaDB?

Here is some testing result, in attempt to clear the picture a bit:

1.  After fresh installation - mediaDB has no entries
2.  After adding media to volDB using robot inventory - mediaDB has no
entries
3.  After tapes been used by the media server - mediaDB contains only the
tapes been used
4.  After Removing mediaDB from the media server, (volDB on master intact):
    a. Restore works fine from previous backups
    b. available_media report shows the tapes, incorrect Status (DBBACKUP),
no Retention Level, no Size of Data Written.
    c. bpmedialist doesn't show information on those tapes anymore
    d. bpexpdate operation on the tape will always report no such media
exist in NB/MM database
    e. vmquery -m option returns everything correctly (information pulled
from volDB).
5.  After the lost of mediaDB, any operation requesting the access of
mediaDB will trigger the creation of a blank new mediaDB.
6.  After the lost of mediaDB, if a restore operation is done using previous
backups, those tapes involved will be added back to new mediaDB, however:
    a. available_media report shows incorrect status
(IMPORTED/FULL/SUSPENDED/FROZEN/MPX), incorrect retention level (with *), no
size of data written.
    b. bpmedialist doesn't show information on those tapes
    c. bpexpdate operation on the tape will always report no such media
exist in NB/MM database.
    d. further backups will not using these media for whatever the funky
reason.
7.  After the lost of mediaDB, move the media to non-robotic and add these
tape back via robot inventory will not create entries in the mediaDB.
8.  I haven't managed to get backups to go onto those tapes after losing
mediaDB - unless of course, when volDB is also blown away, and tapes added
back to volDB, in which case the previous backups will be overwritten.

Conclusion:
Even though one could perform restore of previous backups if mediaDB is lost
as long as volDB is intact, for the full functionality of NBU media
management, it is still necessary to keep mediaDB of integrity as many media
related information is kept in mediaDB.
=============================================



-----Original Message-----
From: Duane Schultz [mailto:duane AT connect.com DOT au]
Sent: Wednesday, 16 May 2001 4:09 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Problems with available_media and state DBBACKUP


We've had some issues at our site with changes in configuration of media
servers, with some media servers losing their drives and becoming simple
clients.

It seems that the machines that used to be media servers may have had media
database information stored on them for the media that they were writing
and tracking, and since they have been decommisioned, the media which they
had configured is giving us grief - the status column in the
available_media report is showing them as DBBACKUP, which from the code
seems to be the catch-all status for when the mediaid cannot be found in
any database.

What should I be doing to fix this ? Reimporting the media doesn't seem to
get anywhere. I still have a filesystem with the data from the previous
installation, but restoring it, restarting the daemons and trying it
again doesn't seem to get anywhere.

What is the procedure for moving media around between media servers ? Is
there a simple way, or is it a matter of nuke the media information and
reimport ?

-- 
| Duane Schultz                               System Manager |
| duane AT connect.com DOT au                connect.com.au pty ltd |
| Tel: +61 3 9251 3676              Level 9, 114 Albert Road |
| Fax: +61 3 9251 3666        South Melbourne 3205 Australia |
_______________________________________________
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>