Veritas mades it look all good and dandy.  However only bpsched is
suspended.  bpduplicate can still run and update the datebase while the
db backup is happening.  bpduplicate doesn't deal with bpsched at all.  It
talks to bpdbm directly and start/stop bptm on the media server side.
There're also many other tools that might update the database while DB
backup is running.  Bear in mind that there's no "lock" on bpdbm during the
DB backup.

Given the fact that most of the database files are ascii, I would say go take
the slight risk and backup the DB whatever way you want.  The officially
sanctioned method doesn't guarantee an atomic DB backup either.

--Mike

> From veritas-bu-admin AT mailman.eng.auburn DOT edu  Thu Feb 24 09:53:25 2000
> 
>      When NetBackup internally calls bpbackupdb, bpsched is
>      put on hold and won't start any new backups until the
>      bpbackupdb finishes.  This guarantees a stable NBU DB
>      is being written to tape.
> 
>      But when bpbackupdb is called by hand, bpsched continues
>      to behave as normal. So you could have a cron job calling
>      bpbackupdb at 9am, but a backups that happens to start at
>      9:01am will be modifying files in the db directories while
>      bpbackupdb is running.
> 
> Such a situation probably won't nastily corrupt your NBU DB backup, 
> but do you want to risk it?  Let's just say if you go to 
> cron-scheduled bpbackupdb calls, you probably want to decree that 
> time to be a "no-backup zone".
> 
> The above was true as of NBU 3.2 circa October.   If anyone knows of 
> a recent patch that makes my info outdated (and hopefully fixed) 
> please correct me!
> 
> rob
> 
> 
> >Look into
> >
> >/netbackup/bin/admincmd/bpbackupdb
> >
> >USAGE: bpbackupdb [{-dpath disk_path} |
> >            {-tpath tape_device_path [-rv recorded_vsn]} |
> >            {-opath optical_device_path [-rv recorded_vsn]}]
> >           [-nodbpaths] [-v] [path...]
> >
> >
> >
> >Ayaz Mudarris -  Consultant       Great Lakes Team
> >Collective Technologies           www.colltech.com
> >Austin, TX                       "Managing Systems and Networks"
> >
> >
> >
> > > -----Original Message-----
> > > From: veritas-bu-admin AT Eng.Auburn DOT EDU
> > > [mailto:veritas-bu-admin AT Eng.Auburn DOT EDU]On Behalf Of Malcor, Daniel
> > > Sent: Wednesday, February 23, 2000 5:37 PM
> > > To: 'veritas-bu AT mailman.eng.auburn DOT edu'
> > > Subject: [Veritas-bu] Vaulting the DB Backup
> > >
> > >
> > >
> > > This seems like something that ought to be somewhat common.
> > >
> > > We would like to be sending a copy of the Veritas Database offsite on a
> > > daily basis. Clearly we could do this in a manual process by changing the
> > > config on a daily basis, but we are looking for automation (after all we
> > > have a HUGE L11000 Tape Library).
> > >
> > > I see that there is a script
> > > "/usr/openv/netbackup/bin/dbbackup_notify" that
> > > is called with the tape ID for the last DB backup. This would
> > > seem like the
> > > place some cleverness, so I'm just looking to see if anyone has done this
> > > before.
> > >
> > > The steps seem to me to be:
> > >
> > > Edit /usr/openv/netbackup/bin/dbbackup_notify so that it creates
> > > and script
> > > that will be run when you want to vault (if it were to vault every time it
> > > would be way to often).
> > >
> > > The vault script would:
> > >
> > > = Mount the last DB Backup tape and a blank tape (does this come from the
> > > scratch pool?)
> > > = Then using dd to tar(?) make a copy
> > >   (I don't think we want to use bpduplicate since this is a DB tape).
> > > = Then eject the copy and return the original to the library
> > >
> > > Simple, no?
> > >
> > >
> > > > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > > Daniel Malcor, UNIX Administrator
> > > > Pacific Life Insurance Company
> > > > Annuities Technology
> > > > Voice: (949) 219-7824
> > > > E-mail: DMalcor AT PacificLife DOT 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
> 
> --
> 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
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 


-- 
Mike Wei       Collective Technologies, a Pencom Company
Email: wei AT colltech DOT com