I've never looked into using that command before. But the problem I see for
most users is that they are wanting to avoid the command line options as
much as possible. And in truth this is best for them (mostly windows users)
since going outside the gui is an invitation for problems with some people.
Scheduling within the gui does not allow more than 2 tapes for catalog
backup so this the option I have proposed to them is the multiple tapes with
the same label to send with their backup sets offsite.

Unix users are more comfortable with command line options and scheduling
then the majority of the windows users I've worked with so I avoid giving
them options outside the gui if I can help it.

Jason Cordes
LeTigre Computing
713.681.8844
jason.cordes AT letigre DOT com

-----Original Message-----
From: Jon Walton [mailto:jonw AT n2h2 DOT com]
Sent: Tuesday, November 05, 2002 9:31 AM
To: jason.cordes AT letigre DOT com
Cc: Veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Catalog backups offsite

Perhaps I am missing something, but why would you not just run:

      /usr/openv/netbackup/bin/admincmd/bpbackupdb [-tpath
tape_device_path  [-rv recorded_vsn]] [-nodbpaths] [-v] [path.. ]

right after your duplications are complete?

-Jon


On Tue, 5 Nov 2002 jason.cordes AT letigre DOT com wrote:

> What I've done in the past is take enough tapes so that I have one for
every
> offsite backup set and give them the same label. I then use that label for
> the catalog backup. When the backups are removed from the library, take
out
> that catalog backup tape and keep it with that backup set. Replace it with
> another tape with the same label and you are set to go for the next round
of
> backups. The problem with this setup is that you need to devise a way to
> keep all these catalog backup tapes separate from each other and always
with
> the backup set it goes with.
>
> Jason Cordes
> LeTigre Computing
> 713.681.8844
> jason.cordes AT letigre DOT com
>
> -----Original Message-----
> From: Bruno.Bossier AT comparex DOT be [mailto:Bruno.Bossier AT comparex DOT 
> be]
> Sent: Tuesday, November 05, 2002 8:02 AM
> To: Veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Catalog backups offsite
>
>
> We also duplicate all our backups, but it seems that it's not possible to
> duplicate a catalog backup.
>
> Any other ideas on how we can let catalog backups go offsite ?
>
>
>
>
>
> 
>
>                     "Alonzo, Alex"
>
>                     <Alex.Alonzo@t       To:
<Bruno.Bossier AT comparex DOT be>
>
>                     rw.com>              cc:
>
>                                          Subject:     RE: [Veritas-bu]
> Catalog backups offsite                   
>                     11/04/2002
>
>                     17:12
>
> 
>
> 
>
>
>
>
>
> Bruno
> We dup all fulls (weekly,monthly, yearly) and send them offsite once a
week
> we do have some clients that don't require Dups on all there fulls so we
> make
> some adjustments to the dup_parms files.
> Alex Alonzo
>
> -----Original Message-----
> From: Bruno.Bossier AT comparex DOT be [mailto:Bruno.Bossier AT comparex DOT 
> be]
> Sent: Monday, November 04, 2002 3:21 AM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] Catalog backups offsite
>
>
> What would be a good process to have daily catalog backups which can go
> offsite ? The idea is to run a catalog backup after every daily or weekly
> cycle and let the tape which was used for this catalog backup go offsite,
> together with the normal backup tapes.
>
> Bruno
>
>
> _______________________________________________
> 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
>