[Veritas-bu] available_media fix + TIR

2000-02-24 18:36:22
Subject: [Veritas-bu] available_media fix + TIR
From: Andy Thomas andy AT pixar DOT com
Date: Thu, 24 Feb 2000 15:36:22 -0800
thanks rob!

i used your tip to write a better script. i made it even faster by only
checking media in the library (using vmquery -rn). we have thousands of
tapes in our database, available_media used to take about 45-50 minutes
and now my script finishes in about 10 seconds. (!)

veritas hasn't touched this script since 03/97, it would be nice if
someone over there would get this fixed.

also, anyone out there that is using TIR should take a close look at
"move detection" in 3.2. i just found out that if you don't activate it
files with unchanged inode and modification times since the last full
that have been renamed or moved will not be picked up by a incremental
TIR backup. so if you needed to do a TIR restore you could wind up with
something that is hardly a "True Image".  in fact, you'd probably be
better off not using TIR at all. I'm assuming this bug existed in
previous versions of NetBackup, but I don't understand why this wasn't
fixed in a patch and instead is being promoted as a new "feature". i
can't think of a situation where you would want to do TIR backups with
"move detection" turned off.

and even worse, rather than fixing the algorithm TIR uses for picking
files, netbackup needs to (in addition to the performance hit and
database overhead of using TIR) collect move detection information and
stores it on the client (?!) instead of the database. what a mess. i
need to get more information from veritas support but right now it
seems like there's no way to do a "real" TIR restore to an alternate
client. if anyone out there has more info on this i'd like to hear it.

one more thing, has anyone tried doing a full restore of a
multiple-stream backup? i'm not using mpx so i would expect a backup
using two streams should also be able to restore in parallel, but
that's not what i'm seeing... i've got an open call on this, but it
would be interesting to hear if this is working for anyone else.

sorry for the rant, but i had to get that off my chest...


On Wed, 23 Feb 2000, Rob Worman wrote:

> Hi Brian-
> Don't necessarily trust the available media script when it tells that 
> a tape's status is DBBACKUP.  It's certainly possible to have "extra" 
> tapes which are marked for DB backups, but more likely it's a bug in 
> the available_media script.  IIRC the bpmedialist call (which is 
> inefficiently called hundreds or thousands of times, depending on how 
> many tapes you have, see fix below) occasionally hits a snag and 
> doesn't return info on one of your tapes and in this case the tape 
> gets the "DBBACKUP" status assigned.
> Here's what I suggest - not only is it a fix, but it will 
> tremendously speed up your available_media script if you have a lot 
> of tapes.  (e.g. surveying 600 tapes takes about 45 seconds instead 
> of 10 minutes)
> Edit the available_media shell script like so:  (I'm looking at a box 
> running 3.1.1 at the moment, but the 3.2 available_media script is 
> identical or close enough)
> =========
> 1--go to the line "cat $VMPOOL_OUTPUT |"
>     (line 152 for me)
> 2--BEFORE this line, add the following command:
>      /usr/openv/netbackup/bin/admincmd/bpmedialist -mlist -l > 
> /tmp/mvedialist.out
>    (this command should be all one line, and that's a
>     lowercase "L" flag, not the digit "1")
> 3--go to the line where bpmedialist is being piped to a while loop
>     (line 177 for me)
> 4--comment out the bpmedialist line, and replace it with the following:
>          grep $vmediaid /tmp/vmedialist.out 2>/dev/null |
>    (don't forget that pipe at the end....)
> ===========
> sorry, the above fix won't necessarily work on an NT Master server :))
> rob
> >All,
> >
> >Being new to this list my question maybe a repeat, if so please point me
> >to the archives and I will be a happy person but.....
> >
> >
> >When I run the available_media script on a 3.2 NBU box I get the
> >DBBACKUP listing on some tapes.  Yes I know how to get rid of it and
> >change it back to the correct pool.  What I am looking for is a way to
> >prevent this from happening.  It is happening with more freq. and would
> >like to solve it not band-aid it.
> >
> >Thanks
> >
> >brian
> >
> >_______________________________________________
> >Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> >
> --
> Rob Worman, Consultant
> Collective Technologies           cell: 612/802-6850
> "The Power of Many Minds"         alpha page: 1-800-946-4646, pin=1422494
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu

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