Veritas-bu

[Veritas-bu] NBDB backup scripts?

2001-01-26 15:21:12
Subject: [Veritas-bu] NBDB backup scripts?
From: W. Curtis Preston curtis AT backupcentral DOT com
Date: Fri, 26 Jan 2001 12:21:12 -0800
"Sufficient" is a tough word.  I don't feel that the documented setup is 
sufficient -- thus the whole discussion of how to write a script to make it 
more sufficient.  HOWEVER, the cron job below is certainly better than 
having nothing. ;)  To make it work, you would set up two tapes, or a tape 
and a disk, and then set the backups to "never," or "manually initiated."

At 12:26 PM 1/26/01 -0600, TWGIBBAR AT up DOT com wrote:


>So, if everything is properly configured through the NetBackup Admin
>interface, would simply running a job out of cron be good enough?
>
>* 0,4,8,12,16,20 * * * /usr/openv/netbackup/bin/admincmd//bpbackupdb
>
>
>
>
>
>"David A. Chapa" <david AT datastaff DOT com>@Eng.Auburn.EDU on 01/25/2001
>01:23:10 PM
>
>Please respond to "David A. Chapa" <david AT datastaff DOT com>
>
>Sent by:  veritas-bu-admin AT Eng.Auburn DOT EDU
>
>
>To:   Dennis Dwyer <dfdwyer AT tecoenergy DOT com>
>cc:   veritas-bu AT mailman.eng.auburn DOT edu
>
>Subject:  RE: [Veritas-bu] NBDB backup scripts?
>
>
>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
>_______________________________________________
>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




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