Hello
Wouldn't you just need to hack the script such that bpduplicate gets
called with the -mpx flag?
Regards,
John
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu@ENRON
> COMMUNICATIONS On Behalf Of "Donaldson, Grant" <DONALDG AT tc.gc DOT ca>
> Sent: Wednesday, October 31, 2001 3:39 PM
> To: 'Tim McMurphy'
> Cc: Veritas BU
> Subject: RE: [Veritas-bu] multiplexed duplicates & vaulting
>
> Hi Tim,
>
> We had a patch created for the previous version of BpVault
> (1.4.0)
> that allowed us to duplicate MPX backup images to a single drive pair
> much
> faster than the standard install of 1.4 (we don't use the BpVault
> generated
> image lists for the duplication part of the vaulting process). This
> modification was ported into version 3.4 of BpVault and is activated
> by
> entering some new parameters into the dup_param file(s). It currently
> allows us to duplicate 188 images on 80 tapes (3 terabytes) in about
> 60
> hours using 1 drive pair. We maintain MPX and have decent drives
> (9840s
> running 20MB/second). If you think this may be of use to you, I would
> contact Lissa Landmark of BpVault at lissa AT veritas DOT com to get more
> info.
>
> *** Please note that it only works with one drive pair.
>
> Grant
> Transport Canada
>
>
> > ----------
> > From: Tim McMurphy[SMTP:Tim.McMurphy AT telus DOT com]
> > Sent: Wednesday, October 31, 2001 10:32 AM
> > To: Veritas BU
> > Subject: RE: [Veritas-bu] multiplexed duplicates & vaulting
> >
> > We have 250 images ranging from 5 gig to 100 gig (total of 2.5
> terabytes)
> > and that takes about 5-6 days to duplicate with de-mux. That is just
> using
> > 1
> > drive for original tape and 1 for duplicate.
> >
> > -----Original Message-----
> > From: Steve Mickeler [mailto:steve AT neptune.on DOT ca]
> > Sent: Wednesday, October 31, 2001 7:45 AM
> > To: Veritas BU
> > Subject: RE: [Veritas-bu] multiplexed duplicates & vaulting
> >
> >
> >
> > I agree. My current vaulting process is still running since Monday @
> 5am,
> > which brings it to 53 hours so far.
> >
> > Im concerned that the vaulting software isnt working correctly
> because its
> > running 4 vault jobs at once, using 4 drives for original tapes and
> 4
> > drives for duplicate tapes.
> >
> > The error logs bpvault.error.0, bpvault.error.1, bpvault.error.2 and
> > bpvault.error.3 show extremely different info.
> >
> > bpvault.error.0 = Status = successfully duplicated 5 of 5 images
> > bpvault.error.1 = Status = successfully duplicated 14 of 14 images
> > bpvault.error.2 = still duplicating images
> > bpvault.error.3 = Status = successfully duplicated 45 of 45 images
> >
> > dup.preview.out shows 180 images to be vaulted, which leads me to
> believe
> > that the last bpvault #2 process is going to take quite a while if
> its
> > vaulting 116 or 180 images based on the number of images vaulted in
> 0,1 &
> > 3.
> >
> > I think something needs to be tuned or tweaked here, cuz this cant
> remain
> > this way.
> >
> >
> >
> > On Wed, 31 Oct 2001, Jason Ahrens wrote:
> >
> > > Although I do have to agree with that, unfortunatly reality
> impinges
> > it's
> > > way into my ideal world. We have a number of large images and to
> go
> > through
> > > the tapes to demux them can take up to 4 hours an image (I've
> timed it).
> > > Given the number of images I'm dealing with here sometimes on a
> daily
> > basis,
> > > there arn't enough hours to a day to demux my duplicates.
> > >
> > > Unless someone knows some secret trick I don't.
> > >
> > > Jason
> > >
> > > > -----Original Message-----
> > > > From: David A. Chapa [mailto:david AT xbpadm-commands DOT com]
> > > > Sent: October 30, 2001 15:29
> > > > To: Steve Mickeler; veritas-bu AT mailman.eng.auburn DOT edu
> > > > Subject: RE: [Veritas-bu] multiplexed duplicates
> > > >
> > > >
> > > > Here's the biggest reason I recommend having de-mux'ed
> > > > duplicated images.
> > > >
> > > > When a tape contains MPX images, it no longer maintains a tar
> > > > compatible
> > > > header. The only way to remedy that is by duplicating
> > > > (de-mux by default)
> > > > the images.
> > > >
> > > > This allows you, independently of an NBU server, to access
> > > > the data with GNU
> > > > tar or Veritas' modified version of GNU tar.
> > > >
> > > > I know there are a lot of opinions on whether this is a good
> > > > enough reason
> > > > to de-mux, and I shall not argue with any of you, it merely
> > > > becomes a matter
> > > > preference.
> > > >
> > > > Most of my clients like to have an industry standard (nearly
> standard)
> > > > format in their offsite vault.
> > > >
> > > > David
> > > > <><><><><><><><><><><><><><><><><><><><>
> > > > David A. Chapa
> > > > NetBackup Consultant
> > > > DataStaff, Inc.
> > > > http://www.consulting.datastaff.com
> > > > 847 413 1144
> > > > ---------------------------------------
> > > > NBU-LSERV AT datastaff DOT com - Adv. Scripting
> > > > http://www.xbpadm-commands.com
> > > >
> > > > -----Original Message-----
> > > > From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> > > > [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of
> Steve
> > > > Mickeler
> > > > Sent: Tuesday, October 30, 2001 1:23 PM
> > > > To: veritas-bu AT mailman.eng.auburn DOT edu
> > > > Subject: [Veritas-bu] multiplexed duplicates
> > > >
> > > >
> > > >
> > > > We're running the vault extension on our netbackup setup and
> > > > I'm finding
> > > > that the time to duplicate is taking a long time. 36 hours to
> > > > duplicate
> > > > 180 images spanning 14 DLT 35B/70GB tapes.
> > > >
> > > > I'm assuming its taking so long to duplicate the images because
> its
> > > > de-multiplexing the images during the duplicate.
> > > >
> > > > Is there any reason why I wouldnt want to have the duplicates
> > > > multiplexed
> > > > ?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Todays root password is brought to you by /dev/random
> > > >
> > > > .-------------------------------------.
> > > > | Steve Mickeler * Network Operations |
> > > > +-------------------------------------+
> > > > | Neptune Internet Services |
> > > > `-------------------------------------'
> > > >
> > > > 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5
> 8D4F
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> >
> >
> >
> > Todays root password is brought to you by /dev/random
> >
> > .-------------------------------------.
> > | Steve Mickeler * Network Operations |
> > +-------------------------------------+
> > | Neptune Internet Services |
> > `-------------------------------------'
> >
> > 1024D/ACB58D4F = 0227 164B D680 9E13 9168 AE28 843F 57D7 ACB5 8D4F
> >
> >
> >
> > _______________________________________________
> > 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
**********************************************************************
This e-mail is the property of Enron Corp. and/or its relevant affiliate and
may contain confidential and privileged material for the sole use of the
intended recipient (s). Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender or reply to Enron Corp.
at enron.messaging.administration AT enron DOT com and delete all copies of the
message. This e-mail (and any attachments hereto) are not intended to be an
offer (or an acceptance) and do not create or evidence a binding and
enforceable contract between Enron Corp. (or any of its affiliates) and the
intended recipient or any other party, and may not be relied on by anyone as
the basis of a contract by estoppel or otherwise. Thank you.
**********************************************************************
|
