Hi John,
You could do that but BpVault does already allow you to use the MPX
option when it calls the bpduplicate command; this is activated by entering
"mpxdup 1" into your dup_param file. I've checked over my problem logs
from a year ago when we first installed BpVault and encountered the
performance issues (painful memories!) and here is a synopsis of what I
found:
In version 3.1 of Netbackup you could create MPX'd originals, but
the bpduplicate command only allowed you to create de-MPX'd images. This
meant that the duplication process would entail multiple tape mounts of the
original tape as the de-MPX'd copies were being created. Version 2.3 of
NetBackup introduced the -mpx parameter to the bpduplicate command, thus
allowing you to maintain MPXing when you created duplicate tapes - no more
multiple tape mounts and therefore greatly improved performance.
Version 1.4 of BpVault introduced the "mpxdup" parameter, thus
allowing you to take advantage of the v3.2 bpduplicate command's new -mpx
parameter to create MPX'd duplicates. This should have meant improved
performance when duplicating MPX'd tapes if you used this parameter to
maintain MPXing. However, we found that the performance was back to the
level encountered during our v3.1 days. While investigating our performance
issue with a Veritas engineer we found that while BpVault was designed to
eliminate multiple tape mounts(using it's image and media lists), we were
encountering an average of 2 or 3 mounts per tape. It appeared to him that
the data was being de-multiplexed(even though we were using the mpxdup
parameter to maintain MPXing). It turned out that BpVault was in fact
writing out the original MPX'd images to the duplicate tape one whole image
at a time, thus losing the MPXing advantage. However, when writing to the
duplicate tape, because of the -mpx option being used with the bpduplicate
command, the data on the duplicate tape was written in MPX format(trying to
simply tar the tape would fail).
Additional work by the BpVault group revealed that bpduplicate works
differently when an image list is used,,,,
"...since apparently the bpduplicate code handles MPXed duplication
differently based on how you call it (either specifying a list of images
like we do, or not specifying a list of images like you guys did).
Just to let you know, this[the patch] should work fine in an environment
with a single pair of tape drives per media server. If you wish to use
mutliple pairs of tape drives for duplication on a given media server, then
you would need to return to the normal way of duplication, and not use this
particular feature I have implemented for Transport Canada. We will be
talking with engineering to see if a core fix to bpduplicate can be made to
address this issue. " Brian Blake, Professional Services Organization,
> VERITAS Software. Wednesday, September 27, 2000 4:33 PM
>
>
So, if you have MPX'd originals, use only 1 drive pair and use
BpVault to handle your duplications, using the non-images based duplication
method may be the way to go for your site.
Best Regards.
Grant
Transport Canada
> ----------
> From: Wang, John[SMTP:John.Wang AT enron DOT com]
> Sent: Wednesday, October 31, 2001 5:09 PM
> To: "Donaldson, Grant" <DONALDG AT tc.gc DOT ca>; Tim McMurphy
> Cc: Veritas BU
> Subject: RE: [Veritas-bu] multiplexed duplicates & vaulting
>
>
> 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.
> **********************************************************************
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
|
