DBBACKUP

[Ben_Davis-Hughe]

Im getting most of my media showing as dbbackup status when using available media. This is causing my jobs to fail does any one have any ideas???

[Stumpr2]

This is a common occurrence when the NetBackup volume pool is defined in a policy for normal backups. First ensure that none of your policies use the NetBackup volume pool. Then keep only a couple of tapes in the NetBackup pool that you are actively using for catalog backups.Then do these three steps.

1. identify all tapes that have been used for catalog backups.
2. deassign the tapes that do not have current catalog info that you may need to do a bprecover.
3. relabel the tapes.
These three steps are outlined in the technote:
How to reuse or recycle unnecessary VERITAS NetBackup database catalog tapes for normal backups
http://seer.support.veritas.com/docs/237779.htm

Here it is: (NOTE: Step 1 can be done many different ways)
Details:
In order to reuse tapes that were previously used for NetBackup database catalog backups, perform the following two steps:

Caution: Once these steps have been performed, the original data on the tape is destroyed and lost - make certain beforehand that verification has been done on all the tapes on which this operation is to be performed, and that they are indeed tapes that can be overwritten!

Perform the following commands on the volume database host (usually the NetBackup master server):

Step 1. Determine which tapes are catalog backup tapes on your system by issuing the following command:

/usr/openv/volmgr/bin/vmquery -a > /tmp/vmquery.out

After the re-directed output file is created - vi (or use editor of choice) the file and search for the status 0x1 (see output below) - this status indicates that it is a catalog backup tape and record the media ID as a catalog backup tape.

After identifying all of the catalog backup tapes, the active catalog backup tapes should be identified (this can be done using the Java GUI, Configure drop down menu, and selecting NetBackup Catalog Backup, viewing the selections for media 1 and media 2 and noting the media IDs. This can also be accomplished by viewing the last mounted category for the status 0x1 tapes from the output below, in the event that only catalog backup tapes older that a certain date are to be reused (a working strategy can be developed to only reuse catalog database tapes older that 1 month, etc.).

Caution: These active catalog backup media IDs must NOT be overwritten or destroyed. Take special care to avoid the following procedure on the active catalog backup media and any other catalog backup media that you wish to keep.

The example of the vmquery -a output below shows two different types of NetBackup tapes. The status 0x0 is a NetBackup backup tape and the status 0x1 indicates a tape that has been used for a NetBackup catalog database backup.
================================================================================
media ID: CAN000
media type: DLT cartridge tape (11)
barcode: --------
description: Added by Media Manager
volume pool: NetBackup (1)
robot type: TLD - Tape Library DLT (8)
robot number: 0
robot slot: 1
robot host: NBsrv1
volume group: 00_000_TLD
created: Thu Apr 05 08:38:01 2001
assigned: Thu Jun 14 10:47:08 2001
last mounted: Thu Jun 14 10:48:35 2001
first mount: Thu Apr 05 09:00:22 2001
expiration date: ---
number of mounts: 3
max mounts allowed: ---
status: 0x0
================================================================================
media ID: 000101
media type: DLT cartridge tape (11)
barcode: --------
description: ------
volume pool: NetBackup (1)
robot type: TLD - Tape Library DLT (8)
robot number: 0
robot slot: 2
robot host: NBsrv1
volume group: 00_000_TLD
created: Thu Apr 05 08:45:00 2001
assigned: Sat Jun 02 08:35:06 2001
last mounted: Fri Jun 22 01:44:28 2001
first mount: Thu Apr 05 08:45:52 2001
expiration date: ---
number of mounts: 14
max mounts allowed: ---
status: 0x1
================================================================================

Step 2. /usr/openv/volmgr/bin/vmquery -deassignbyid

i.e. /usr/openv/volmgr/bin/vmquery -deassignbyid 000101

(where 000101 is the tape volume ID)


Step 3. /usr/openv/netbackup/bin/admincmd/bplabel -ev evsn -d density

i.e. /usr/openv/netbackup/bin/admincmd/bplabel -ev 000101 -d dlt (in this case 000101 is the tape volume ID, dlt is the tape density, and assumes that a robotic library exists and the tape is in the library. If it is a standalone tape drive system, a drive name will have to be specified in the command line).

Note: If this is a standalone tape system, the tape must already be in the drive specified above - this may take manual intervention.

These steps will remove the information from the volume database and write a new label to the tape, effectively erasing any previous information on the tape, which can now be used for NetBackup backups.


Related Documents:

247804: How to re-use a NetBackup tape for Catalog backups (status code 97 is generated when configuring a Catalog backup).
http://support.veritas.com/docs/247804Message was edited by:
Bob Stump

[TempoVisitor]

Hya

This available_media script is a big mistake !!!!!

1st - It's only a script
2nd - it's slow
3rd - it uses 2 very fast binaries, bpmedialist and vmquery that gives u the info u want if u know where to look for it
4th - when your mediaDB is corrupted, or one of ur server is out, available_media tells you the assigned volumes are all DBBACKUP

If you still want to use available_media, I just modified it, both Winodws and Unix version, in order to say a volume is orphan iinstead of DBBACKUP.

Don't consider however that this status prevent your NBU to work. What it means is you have lost your mediaDB !!! This is much more important.

Look at Bob message for checking the vmquery status of the media : if it's 1, it means it's a real catalog backup tape. You might want to relabel it.
If it's 0 : it means there might be some data on the tape and the tape is assigned. This prevents NBU to overwrite the data.

I think what you forgot to tell us is that you made a migration from a server to another one, or made a recover of your catalog. In both cases, you may have forgotten the mediaDB behind you. Or else one of your media Server is out !

NetBackup cant append any data on theses volumes, however you can still restore your previous images. NBU does not need the mediaDB for restore, only to check who is the tape owner and has the right to append data.

anyway, if you still want the available_media_plus script, just ask : kerkael@hotmail.com

Kerk the noob

[Richard_Bannist]

No Kerkael, that's all wrong about available_media script...

your point 2 is wrong. The clue to the real cause is your point 4....Have pretty much copy/pasted my findings on this subject back in 2002. --->

This technote from 2002 has been updated, ie this longstanding bug is still with us, and the fix is exactly the same as I applied back then, so have amended & tested. Thought something was wrong, available_media script was taking upwards of 4mins since upgrade to 4.5; now the script takes 20seconds…..

The available_media script incorrectly lists a volume's status as DBBACKUP and script execution time is slow when many tapes exist in the mediaDB.

TechNote ID: 199300 Last Updated: March 30 2004 05:47 AM GMT
______________________________________________
From: Richard Bannister @ Northampton
Sent:29 January 2002 14:40
To:Richard Bannister @ Northampton
Subject:Bug in official available_media script, & workaround

http://seer.support.veritas.com/docs/199300.htm

Symptom:
The available_media script incorrectly lists a volume's status as DBBACKUP and script execution time is slow when many tapes exist in the mediaDB.

Solution:
While the available_media script is a very useful tool and is used by many, it is not formally supported and only exists in the goodies directory.

There is a timing problem in the current version of the available_media script that can result in normal NetBackup tapes being reported as DBbackup tapes. This timing problem in the available_media script is related to the IIRC the bpmedialist call (see fix below) occasionally hits a snag and doesn't return info on one of the tapes. There is a limitation in the available_media script, the script assigns a status DBBACKUP to any tape it cannot find a legitimate status for, e.g. FULL, AVAILABLE, ACTIVE, etc.

This suggestion is proposed not only as a work around, but as a possible fix to the underlying root cause as well. It also has the side benefit of providing a significant improvement in the execution time of the available_media report. There are claims of the available_media report seeing a 30x improvement for UNIX servers.

This workaround performs a single action to capture the status of all tapes to a temporary file and then just reads entries from this file (from a box running 3.1.1 but the problem also exists in 3.2 and the script has also not changed in 3.4). Edit the available_media shell script as follows:


=========
1) Go to the line "cat $VMPOOL_OUTPUT |"
(line 152)

2) BEFORE this line, add the following command:
/usr/openv/netbackup/bin/admincmd/bpmedialist -mlist -l > /tmp/medialist.out

(this command should be all one line, and that's a
lowercase "L" flag, not the digit "1")


available_media script snippet start
…
…
VMQUERY_OUTPUT=/tmp/vmquery.out
ASTERISK_DISPLAYED=/tmp/asterisk_displayed

###### Add this next line
/usr/openv/netbackup/bin/admincmd/bpmedialist -mlist -l >/tmp/medialist.out
cat $VMPOOL_OUTPUT |
while read poolname poolhost pooluser poolgroup pooldesc
do
…
…
available_media script snippet end

3) Go to the line where bpmedialist is being piped to a while loop

4) Comment out the bpmedialist line, and replace it with the following:
grep $vmediaid /tmp/medialist.out 2>/dev/null |
(don't forget that pipe at the end....)

available_media script snippet start
…
…
else
###### Comment Out This Line
# /usr/openv/netbackup/bin/admincmd/bpmedialist -mlist -l -ev $vmediaid 2>/dev/null |
###### Add this next line
grep $vmediaid /tmp/medialist.out 2>/dev/null |
while read bpmediaid bppartner bpver bpden bpalloc bplwrite bpexp bplrest bpkbytes bpnimages bpvimages bpretlev bpunused1 bpnumrest bpstat bprest
do
…
…
available_media script snippet end


Note: The above fix won't necessarily work on a NT Master server and this problem has been reported to Engineering.
--------------------------------------------------------------------------------


Regards
Richard

p.s. the available_media script is excellent, it's a damn shame Veritas only support it unofficially/can't guarantee it won't be phased out or replaced.

A lot of my custom scripts/reports are based on the output from available_media

[TempoVisitor]

The UNIX version of available_media is time consuming because it makes a loop on the bpmedialist output.
So it's function of the number of volumes in your volDB.

The WIndows version is long because it launches the bpmedialist command on each volume found in the volDB.

It really depends on the number of tapes you want to get information about.

Just try this :
time bpmedialist -U
time vmquery -a -bx
time available_media

With only 10 tapes you may have 3 to 4 seconds for available_media whereas the binaries commands bpmedialist and vmquery take less than half a second each.

With 100 tapes, or 1000 tapes ... good luck, whatever changes you make to available_media, you will have to wait a loooooong time.

Kerk

[Stumpr2]

funny thing about this thread "available_media" some curse it and some embrace it.
There is a posting just this morning on the Veritas-bu@mailman.eng.auburn.edu mailing list from another Richard with a perl script modification to available_media.

New available media script Richard Hellier

you can get to the email post via
http://mailman.eng.auburn.edu/pipermail/veritas-bu/2005-February/thread.html

I hope these links show up alright.Message was edited by:
Bob Stump

[Richard_Bannist]

ah, i omitted a comment, i meant to add that 'your milage may vary'. I was concerned less with amount of tapes etc etc, but the previous post re available_media (to me anyhow) suggested the symptoms from the age-old bug that is still present in 4.5. With the available_media bug(s) corrected, even with many 100s of tapes it should not be an unacceptable time to wait. In my humble opinion of course :)

RichMessage was edited by:
Richard Bannister

[TempoVisitor]

Is this believable the main problem of the available_script : (DBBACKUP media when your mediaDB is corrupted instead of an ORPHAN flag ) has been left or reproduced in this perl version Bob talks about ?

These developers are crazy ! It's still easy to test the volDB status, from vmquery to see a status 1 should be a real DBBACKUP and a status 0 not present in mediaDB is an ORPHAN tape .. pffffff

Kerk