Dennis:
In order to be in compliance with the 'supported'
method of backup and recovery of your NetBackup
databases (chapter 5 of the Troubleshooting guide), you
really should be backing up the Netbackup DBs to tape
using bpbackupdb (which is invoked automatically when
configured through your NetBackup Admin interface).
Your method currently is still a good idea, but there
is also the case when a backup runs and there are open
files for one reason or another, or a prune job is
running, etc. on the server you are trying to backup
and the consistency of the Netbackup databases are then
in question.
I would say that you may be putting your environment at
risk by not using bpbackupdb to backup the databases
properly.
David
Quoting Dennis Dwyer <dfdwyer AT tecoenergy DOT com>:
> I see all this exchange about backing up the
NetBackup database and the
> obnoxiousness of it all and it makes me question what
I'm doing because I
> don't do it the normal way. Let me run this by you to
see if I'm setting
> myself up for failure.
>
> My NBU environment consists of two Sun E450's acting
as Master servers (no
> media servers) running Solaris 2.6 and NBU 3.2GA.
Each server has it's own
> attached tape library. When I built the NBU
environment on each server, I
> used Veritas Volume Manager to build a separate file
system for the NBU
> database directory and the and the NetBackup Volume
Manager database
> directory. I do a FULL backup each day of the NBU
Master servers (after all
> the backups have completed) and my thinking is if I
had to recover the NBU
> databases, I could just restore each file system. I
came to that conclusion
> because the only directories backed up in the built-
in NBDB backup process
> are the NetBackup and volume manager database
directories. Obviously my
> operation is fairly small (about 191 servers total)
and it's probably less
> complicated since I have no media servers, but I
guess I need to know if
> anyone sees a flaw in my plan. I have a pool of tapes
in each library
> dedicated to the backup of each NBU master server and
they are located in
> Slot 1 & 2. Each tape has a different bar code
pattern than all others in
> the library and I can easily open the door and grab
those two tapes if I
> had to and import then into a new, bare bones
recovered server for use to
> recover my NBU master to its previous state. Each
master is backed up to
> the other and the masters are not located in the same
building (they are 10
> miles apart).
>
> What do you think? Am I a catastrophe just waiting to
happen or is my plan
> viable?
>
> Regards,
> Dennis
>
> Quote: "Time is not a test of the truth"
> Translation: Just because you've always done it that
way, doesn't make it
> right
>
> Dennis F. Dwyer
> Enterprise Storage Manager
> Tampa Electric Company
>
> (813) 225-5181 - Voice
> (813) 275-3599 - FAX
>
> Visit our corporate website at www.tecoenergy.com
>
> >>> "David A. Chapa" <david AT datastaff DOT com> 01/25/01
09:41AM >>>
> Curtis:
>
> A couple of thoughts
>
> 1. Why not have a pool of tapes dedicated to NBDB
from
> the beginning?
>
> 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.
>
> 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)
>
> 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.
>
> Just some thoughts.
>
> david
>
>
>
> Quoting "W. Curtis Preston"
<curtis AT backupcentral DOT com>:
>
> > No, it works. I just have trouble with all the
> things AROUND bysyncinfo:
> >
> > 1. Finding/getting an UNUSED tape in the NetBackup
> pool.
> > 2. Protecting the tapes that used to be the NDBD
> backup tapes from being
> > overwritten.
> >
> > Here's the script that I am currently using. I've
> taken some of the error
> > checking and functions out for brevity. I think
it's
> working in its
> > current form. I'm open to suggestions.
> >
> >
> >
>
########################################################
> #####
> > # FIRST
> SECTION: #
> > # INITIALIZE
> VARIABLES #
> >
>
########################################################
> ### #
> >
> > robot_num=0
> > scratch_pool=`grep
> SCRATCH_POOL /usr/openv/volmgr/vm.conf |awk '{print
> > $3}'`
> > pool_num=1
> > db_pool_num=2
> > VOLTYPE=dlt
> >
> >
>
########################################################
> #####
> > # SECOND
> SECTION: #
> > # BUILD A LIST ($VOLIDS) of volumes that are in the
> scratch #
> > # pool and in the robot that we are
> using #
> >
>
########################################################
> ### #
> >
> > #Identifies all volumes in the robot numbers
current
> volume database and
> > redirects to outfile
> > vmquery -b -rn $robot_num | egrep -v '^media|^
*ID|^-
> ------' |awk '{print
> > $1}' \
> > >/tmp/$$.tapesinrobot 2>/tmp/$$.errors
> >
> > #Identifies all volumes that are a part of the
> Scratch pool on robot_num
> > and assigns to VOLIDS
> > VOLIDS=`vmquery -b -pn $scratch_pool | egrep -
> v '^media|^ *ID|^-------' \
> > |awk '{print $1}'`
> >
> > #For each VOLID in VOLIDS check to see if the tape
is
> part of the scratch
> > pool
> > #and in the robot, if true break
> >
> > for VOLID in $VOLIDS ;do
> > grep $VOLID /tmp/$$.tapesinrobot >/dev/null
> > [ $? -eq 0 ] && INVOLIDS="$INVOLIDS $VOLID"
> > done
> >
> >
> >
>
########################################################
> ######
> > # THIRD
> SECTION: #
> > # For each volume in the list, try to assign it to
> the db #
> > # backup pool and back up the database. If it's
> successfull,#
> > # we move on, if not, we try with the next
> volume #
> >
>
########################################################
> ######
> >
> >
> > for VOLID in $INVOLIDS ; do
> >
> > #Put the volume into the NetBackup pool
> > vmchange -p $pool_num -m $VOLID 2>/tmp/
> $$.errors
> >
> > if [ $? -gt 0 ] ; then
> > continue
> > fi
> >
> > #Put the volume into the "bpdb pool"
> > bpsyncinfo -id1 $VOLID -d1 $VOLTYPE 2>/tmp/
> $$.errors
> >
> > if [ $? -gt 0 ] ; then
> > continue
> > fi
> >
> > #I like the logic in the other script about
> checking to see if
> > #jobs are running. I think I'll add that
> here in a while loop
> >
> > #Back up the database
> > bpbackupdb -v 2>/tmp/$$.errors
> >
> > if [ $? -gt 0 ] ; then
> > MYERROR=1
> > else
> > MYERROR=0
> >
> > #Take it OUT of the "bpdb pool"
> > bpsyncinfo -delete $VOLID
> >
> > #Put into a special pool
> > vmchange -p $db_pool_num -m $VOLID
> 2>/tmp/$$.errors
> >
> > break
> >
> > fi
> >
> > done
> >
> > if [ $MYERROR -gt 0 ] ; then
> > ERROR="Could not backup NetBackup database
> AT ALL!"
> > Exit #Exit function
> > else
> > DATE=`date`
> > echo "$DATE: \c"
> > echo "Backed up database to volume
$VOLID\n"
> \
> > |tee -a /tmp/$$.log
> > echo $VOLID >>/usr/openv/local/data/db-
> backup-tapes.txt
> > fi
> >
> >
>
########################################################
> ######
> > # FOURTH
> SECTION: #
> > # This takes the oldest tape (out of $NUMBDBTAPES)
> and puts #
> > # it back into the scratch
> pool. #
> > # This keeps a set of tapes that contain the most
> recent db #
> > # backup
> tapes. #
> >
>
########################################################
> ######
> >
> >
> > DBTAPES=`grep -c . /usr/openv/local/data/db-backup-
> tapes.txt`
> > while [ $DBTAPES -gt "$NUMDBTAPES" ] ; do
> > TAPE=`head -1 /usr/openv/local/data/db-
> backup-tapes.txt`
> > echo "There are over $NUMDBTAPES database
> backup tapes: Relabeling
> >
> > $TAPE." \
> > |tee -a /tmp/$$.log
> >
> > #It's assigned to the database backup, so
we
> have to deassign it
> > vmquery -deassignbyid $TAPE $db_pool_num
0x0
> >/dev/null
> > 2>/tmp/$$.errors
> >
> > #Now we put it back in the scratch pool
> > vmchange -p $scratch_pool_num -m $TAPE
> 2>/tmp/$$.errors
> >
> > #Label it just to make sure all is OK
> > bplabel -ev $TAPE -d $VOLTYPE -p
> $scratch_pool -o 2>/tmp/$$.errors
> >
> > grep -v "^$TAPE$" /usr/openv/local/data/db-
> backup-tapes.txt
> > >/tmp/$$.X
> > mv /tmp/$$.X /usr/openv/local/data/db-
backup-
> tapes.txt
> > DBTAPES=`grep -
c . /usr/openv/local/data/db-
> backup-tapes.txt`
> >
> > done
> >
> > echo "\nThis is the current list of database backup
> tapes in the " |tee -a
> > /tmp/$$.log
> > echo "order they were created:" |tee -a /tmp/$$.log
> >
> > cat /usr/openv/local/data/db-backup-tapes.txt |tee -
> a /tmp/$$.log
> >
> > - ---
> > W. Curtis Preston, Principal Consultant at
Collective
> Technologies
> > Email: curtis AT colltech DOT com (Best way
> to contact me)
> > Work : 408 452 5555 (Leave a
> message.)
> > Pager: 800 946 4646, pin#1436065 (If urgent.)
> >
> > Tap into the Collective Intellect (TM):
> http://www.colltech.com
> > Backup & Restore resources:
> http://www.backupcentral.com
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 6.5.3 for non-commercial use
> <http://www.pgp.com>
> >
> >
>
iQA/AwUBOeIOnn9C1rqc6zS7EQISbACg+CjMAqj9kQFWWxvYYwZquzfZ
> eBkAnj/I
> > f3PShgyC+ngBlfXbiKTGtT6g
> > =+zQd
> > -----END PGP SIGNATURE-----
> >
> > At 04:04 PM 1/24/01 -0800, KevinB AT paccessglobal DOT com
> wrote:
> > >Are you saying that bpsyncinfo does not work per
> it's usage statement?
> > >
> > >-----Original Message-----
> > >From: W. Curtis Preston
> [mailto:curtis AT backupcentral DOT com]
> > >Sent: Wednesday, January 24, 2001 3:21 PM
> > >To: Steve Moccio; david AT datastaff DOT com; Bob Bakh
> > >Cc: W. Curtis Preston; veritas-
> bu AT mailman.eng.auburn DOT edu
> > >Subject: RE: [Veritas-bu] NBDB backup scripts?
> > >
> > >
> > >Thanks for the script.
> > >
> > >This solves ONE of the problems with the NBDB
> backup, but not the biggest
> > >one.
> > >
> > >I've been working on a script to automated
swapping
> out the NBDB tapes.
> > (I
> > >really don't like the default setup that
alternates
> between two tapes.)
> > >
> > >At 01:18 PM 1/24/01 -0500, Steve Moccio wrote:
> > > >Hello all,
> > > >
> > > >I too was in the advanced class and received a
> handout about the script.
> > >Not
> > > >sure if this is what you are looking for Bob.
> > > >
> > > >Steve Moccio
> > > > Bell Labs
> > > > svm AT lucent DOT com
> > > >
> > > >
> > > >
> > > >#!/bin/ksh
> > > >
> > > ># find out how many currently queued, re-queued,
> or active jobs
> > > ># there are currently
> > > >QUEUED=`bpdbjobs - summary | sed -e '/MASTER/d'
|
> awk '{print $2}'`
> > > >REQUEUED=` bpdbjobs - summary | sed -
e '/MASTER/d'
> | awk '{print $3}'`
> > > >ACTIVE=` bpdbjobs - summary | sed -e '/MASTER/d'
|
> awk '{print $4}'`
> > > >
> > > ># If there are no queue, re-queued, or active
> jobs, then it is ok.
> > > ># to initiate netbackup DB backup
> > > >
> > > >if [ $QUEUED -eq 0] && [ $REQUEUED -eq 0 ] && [
> $ACTIVE -eq 0]
> > > >then
> > > > #Stop the request daemon
> > > > echo "Stopping the request Daemon"
> > > > bprdreg -terminate
> > > > echo "bprd Daemon terminated"
> > > > # Run netbackup database backup
> > > > echo "Running netbackup database backup"
> > > > bpbackupdb
> > > > echo "Database backup complete"
> > > > # restart request daemon
> > > > echo "Restarting request daemon"
> > > > bprd
> > > >else
> > > > echo "Could not initiate netbackup
> database backup
> > > >fi
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: veritas-bu-admin AT Eng.Auburn DOT EDU
> > > >[mailto:veritas-bu-admin AT Eng.Auburn DOT EDU]On
Behalf
> Of David A. Chapa
> > > >Sent: Wednesday, January 24, 2001 11:47 AM
> > > >To: Bob Bakh
> > > >Cc: W. Curtis Preston; veritas-
> bu AT mailman.eng.auburn DOT edu
> > > >Subject: RE: [Veritas-bu] NBDB backup scripts?
> > > >
> > > >Bob:
> > > >
> > > >I teach that class, and I don't remember an NBDB
> backup script?
> > > >
> > > >that's not to say that it can't be done, it most
> definitely can.
> > > >
> > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >David A. Chapa
> > > >Consulting Manager
> > > >DataStaff, Inc.
> > > >847 413 1144
> > > >
> > > >On Wed, 17 Jan 2001, Bob Bakh wrote:
> > > >
> > > > > I remember one in the NetBackup advanced
class,
> if someone has taken
> > >that
> > > > > class they may have it. I can't find my
course
> material, but If I
> > find
> > >it
> > > > > I'll forward it to you.
> > > > >
> > > > > Bob
> > > > >
> > > > > -----Original Message-----
> > > > > From: W. Curtis Preston
> [mailto:curtis AT colltech DOT com]
> > > > > Sent: Tuesday, January 16, 2001 12:44 PM
> > > > > To: veritas-bu AT mailman.eng.auburn DOT edu
> > > > > Subject: [Veritas-bu] NBDB backup scripts?
> > > > >
> > > > >
> > > > > Does anyone have what they consider to be a
> good NBU database backup
> > > >script?
> > > > >
> > > > > I've tried to write a script to do the
> following, but have been
> > > > > unsuccessful:
> > > > >
> > > > > 1. Swap in a new DB backup tape daily
> > > > > 2. Protect the OLD DB backup tapes from use
> > > > > 3. Backup the database on demand (whenever
the
> script is run)
> > > > >
> > > > > Does anyone have a good script for this?
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > W. Curtis Preston, Principal Consultant at
> Collective Technologies
> > > > > Email: curtis AT colltech DOT com
(Best
> way to contact me)
> > > > > Work : 408 452 5555
> (Leave a message.)
> > > > > Pager: 800 946 4646, pin#1436065 (If
> urgent.)
> > > > >
> > > > > Tap into the Collective Intellect (TM):
> http://www.colltech.com
> > > > > Backup & Restore resources:
> http://www.backupcentral.com
> > > > >
> > > > >
_______________________________________________
> > > > > Veritas-bu maillist - Veritas-
> bu AT mailman.eng.auburn DOT edu
> > > > >
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
> bu
> > > > >
_______________________________________________
> > > > > Veritas-bu maillist - Veritas-
> bu AT mailman.eng.auburn DOT edu
> > > > >
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
> bu
> > > > >
> > > >
> > > >_______________________________________________
> > > >Veritas-bu maillist - Veritas-
> bu AT mailman.eng.auburn DOT edu
> > >
>
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
> bu
> > >
> > >_______________________________________________
> > >Veritas-bu maillist - Veritas-
> bu AT mailman.eng.auburn DOT edu
> >
>
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
> bu
> > >_______________________________________________
> > >Veritas-bu maillist - Veritas-
> bu AT mailman.eng.auburn DOT edu
> >
>
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
> bu
> >
> > _______________________________________________
> > Veritas-bu maillist - Veritas-
> bu AT mailman.eng.auburn DOT edu
> >
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
> bu
> >
>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> David A. Chapa
> Consulting Manager
> DataStaff, Inc.
> 847 413 1144
> _______________________________________________
> Veritas-bu maillist - Veritas-
bu AT mailman.eng.auburn DOT edu
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
bu
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David A. Chapa
Consulting Manager
DataStaff, Inc.
847 413 1144
|
