C-

>>So what you are saying is that I could do something like this:

Yes, exactly.  And you can get the pool number by using vmpool -listall if
you'd like.

>>So would that change the volume's status to the same "0x01" status, like
doing it the
>>other way?

I'm not sure what you mean here, I know when you assign tape to be dedicated
to the DB Backup process, netbackup will assign those tapes, even though
they have never (potentially) been written to, it assigns them for exclusive
use to this utility (bpbackupdb).

The problem when we do these backups outside of this internal process is
that WE need to keep track of these tapes and which have been used and which
one should be next, etc.  Which is why a separate Volpool is a good idea.
That is what I would use the DBBACKUP_CALLED text file for because each time
we do a dbbackupdb, part of the information that is written to this file is
the media id that was used for the process.  Therefore, if your client wants
to have say 5 db backup tapes in a rotation, then I would use that text file
and perform my tests to determine the next tape in the sequence to be used.
(does that make sense?)

By the way you are correct about the -f mountpoint_file switch with tpreq.

And incidentally, the -bx switch for vmquery will give you an all columns
display, much like you would see in the motif interface (xvmadm).


Hope this helps.

David




-----Original Message-----
From: W. Curtis Preston [mailto:curtis AT backupcentral DOT com]
Sent: Thursday, January 25, 2001 6:39 PM
To: David A. Chapa; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] NBDB backup scripts?


Thanks for the input.  Please see my responses below.

At 06:41 AM 1/25/01 -0800, you wrote:
>Curtis:
>
>A couple of thoughts
>
>1.  Why not have a pool of tapes dedicated to NBDB from
>the beginning?
>
>3. I'm not sure why you need to use bpsyncinfo to add
>the mediaid for the db backup if you are manually
>kicking off the bpbackupdb, unless you are doing it to
>ensure the db paths are consistent.  But you can get
>that using bpsyncinfo and then direct the bpbackupdb to
>use a pool other than NetBackup (bpsyncinfo -l and it
>is the 14th field and following if I'm not mistaken)

Because I thought that was the only way to do it until you forced me to
look at the man page. ;)  So what you are saying is that I could do
something like this:

pool_num=(Pool number for NDDB_Backups pool.)

vmchange -p $pool_num -m $VOLID

/usr/openv/volmgr/bin/tpreq -rv rvsn -a w -d dlt -p NDBD_Duplicates -f
/var/tmp/somefile.txt

#Tpreq makes a file that's a symbolic link to the real drive, right?
#If not, what does the file look like?  What does it look like on NT?
device=`ls -l /var/tmp/somefile.txt|awk '{print $11}'`

/usr/openv/netbackup/bin/admincmd/bpbackupdb -tpath $device -rv $VOLID -v

/usr/openv/volmgr/bin/tpunmount -f /tmp/somefile.txt -force


---------------
So would that change the volume's status to the same "0x01" status, like
doing it the other way?

>2.  If you don't like that idea, then for your tape
>selection you may want to use the DBBACKUP_CALLED file
>to see which tape(s) have been used the last X times.
>Using the dbbackup_notify script will cat the
>DBBACKUP_CALLED file and included that in an email to
>someone_who_cares for tracking the last tape used.

Not sure what the benefit is of this one.

>4. You probably have a very good reason for doing this,
>but what I do to streamline my selection process of
>tapes in the robot is to use the -bx switch with
>vmquery then grep for TLD (if it is Tape Library DLT)
>for instance.  Functionally, it doesn't affect your
>script operation and what you are trying to accomplish
>(as you well know), but just an FYI.  I also use this
>extended listing to see if a tape is truly 'scratch' by
>testing the time assigned column, if it doesn't eq ---
>then I know that it is in use.

Uh, no.  I've just never heard of the -bx switch.  Can you send me what the
output looks like?  (As I said, I'm not a client right now.)