What Peter says is true, but you'll want to make sure 
that when you do the backups from cron that you write a 
wrapper script that ensures no backups are active and 
no backups will be able to queue up.  To do this you'd 
want to bring netbackup 'down' by stopping the request 
daemon.  

David
"Yes, I'm still on holiday"

Quoting "Peter L. Buschman" <plb AT iotk DOT com>:

> 
> Paul,
>
> I'd recommend disabling automatic backups from within 
the NetBackup
> scheduler completely.  For an active system
> like yours, neither of the two options, performing a 
database backup after
> a successful schedule or backup, is going
> to be effective.  On such a system, you not only run 
the risk of not
> getting any database backups like you are now,
> but possibly getting them too frequently.  In the 
latter case, you can end
> up with both of your database backup tapes
> overwritten in a matter of hours, something that can 
be disastrous if it
> happens following a corruption event.
>
> Automatic backups can also leave your system unable 
to run jobs for large
> blocks of time if the indexes are large.  I've
> seen some systems that were running an hourly 
schedule and backing up the
> databases after every successful schedule.
> On this system, it took half an hour for the database 
backup to complete,
> so for 30 minutes out of every hour, no backups
> could run.  This eventually caused lots of hourly 
backups to miss, not to
> mention wearing out the database backup tapes
> by writing to each one 12 times every single day.
>
> I nearly always disable the automatic database 
backups and instead schedule
>
> bpbackupdb to run twice a day from cron.
> This way, I always have two valid database copies 
within the past 24
> hours.  With scripting, it is also possible to get 
around
> NetBackup's two media ids for database backups 
limitation as well.
>
> Regards,
>
> --PLB
>
> At 01:24 PM 12/21/2001 -0500, Winkeler, Paul wrote:
> >Greg
> >
> >That sounds like it might be the cause of the 
problem;  Our backup
> schedule
> >is pretty much active 24 hours a day, 7 days a 
week.  At night we run the
> >usual plethora of system backups but in the wee 
hours of the morning we
> >split off a mirror of a 2.5Tb database and its 
backup takes the better
> part
> >of the day (mixed with steady stream of Oracle 
archive logs) until the
> whole
> >process repeats itself come evening time.
> >To eliminate further confusion as to how the NB 
database backup is
> >configured, here is the output of bpsyncinfo:
> >-----------------------------------------------------
---------
> >Frequency of DB Backup:  after each successful 
backup schedule
> >
> >   Server: bkupsrv1.bkup
> >   Sequence # 1    Last Media Used: S00413
> >
> >      Written            Allocated          Type   
Density  Media
> >      -----------------  -----------------  ----   --
-----  -----
> >   1  12/09/01 12:59:07  02/12/01 10:28:28  RMedia 
dlt      S00413
> >   2  12/06/01 12:36:07  12/04/01 17:19:18  RMedia 
dlt      S03640
> >
> >   Paths Included:
> >     opscenter.bkup:/usr/openv/netbackup/db
> >     opscenter.bkup:/usr/openv/volmgr/database
> >     bkupsrv1.bkup:/usr/openv/netbackup/db
> >     bkupsrv1.bkup:/usr/openv/volmgr/database
> >     bkupsrv2.bkup:/usr/openv/netbackup/db
> >     bkupsrv2.bkup:/usr/openv/volmgr/database
> >-----------------------------------------------------
---------
> >The DBBACKUP_CALLED log file has these last few 
lines:
> >-----------------------------------------------------
---------
> >Sun Dec 9 13:29:31 EST 2001 NetBackup databases 
backed up on TAPE S00413
> >Sun Dec 9 13:37:31 EST 2001 NetBackup database 
backup FAILED to TAPE
> S03640
> >Mon Dec 10 23:01:37 EST 2001 NetBackup database 
backup FAILED to TAPE
> S03640
> >Mon Dec 10 23:03:17 EST 2001 NetBackup database 
backup FAILED to TAPE
> S03640
> >Tue Dec 11 18:43:14 EST 2001 NetBackup database 
backup FAILED to TAPE
> S03640
> >-----------------------------------------------------
---------
> >indicating that there haven't even been attempts to 
do a backup since last
> >December 11th!
> >
> >-----Original Message-----
> >From: Greg Nelson [mailto:greg.nelson AT veritas DOT com]
> >Sent: Friday, December 21, 2001 12:57 PM
> >To: 'Winkeler, Paul'
> >Subject: RE: [Veritas-bu] Sporadic, if not erratic 
NB database backups
> >
> >
> >Paul
> >
> >Make sure you don't have any ACTIVE backups that are 
hanging around for
> >days.  If a scheduled backup completes but others 
are running then the
> >catalog backup will not take place.  The catalog 
backup will only run when
> >the NBU environment is inactive.
> >
> >-----Original Message-----
> >From: Winkeler, Paul [mailto:PWinkeler AT officemax DOT com]
> >Sent: Friday, December 21, 2001 11:36 AM
> >To: veritas-bu AT mailman.eng.auburn DOT edu
> >Subject: RE: [Veritas-bu] Sporadic, if not erratic 
NB database backups
> >
> >
> >On any given day we typically run upwards of 450 
jobs through the
> scheduler;
> >In spite of what we feel are high failure rates 
(roughly one every other
> >day), the majority of the runs go through without a 
hitch.  The
> >configuration tool states my NB database backup 
schedule options are:
> >         1) Never (i.e. manual)
> >         2) After each succesfull schedule
> >         3) After each succesfull archive
> >We currently use option 2.  But I am not seeing any 
NB backup activity for
> >weeks on end!  How can this be?  What constitutes a 
successful schedule?
> >
> >-----Original Message-----
> >From: Larry Kingery 
[mailto:larry.kingery AT veritas DOT com]
> >Sent: Friday, December 21, 2001 12:16 PM
> >To: Winkeler, Paul
> >Cc: veritas-bu AT mailman.eng.auburn DOT edu
> >Subject: Re: [Veritas-bu] Sporadic, if not erratic 
NB database backups
> >
> >
> >A successful backup session means that at least one 
of the backups
> >which ran was successful.  A single backup failure 
does not cause the
> >NBU database to not get backed up.
> >
> >If all backups fail, the NBU db backup doesn't 
execute, which makes
> >sense since there's effectively no new info in the 
db.
> >
> >Winkeler, Paul writes:
> > >
> > > We are set up to backup the NB database upon 
successful completion of
> the
> > > backup schedule.  Could it truly be the roughly 
one media error a day
> that
> > > causes us to barely do one NB database backup 
every week?
> > >
> > > If so, what *should* we set the NB backup 
schedule to?
> > >
> > > Getting even more nervous,
> > >  Paul Winkeler
> > > _______________________________________________
> > > Veritas-bu maillist  -  Veritas-
bu AT mailman.eng.auburn DOT edu
> > > 
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-
bu
> >
> >--
> >Larry Kingery
> >                      Of couse, I could be wrong.
> >_______________________________________________
> >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
http://www.consulting.datastaff.com
---------------------------------------
http://www.xbpadm-commands.com
NBU-LSERV AT datastaff DOT com - Adv. Scripting