If you are doing MPX on a tape drive and have a single policy allowing 4 jobs
AND you use Multiple data streams, then this one system will start 4 jobs in
the policy and put all of the backup jobs on the same tape with the data
multiplexed.
My opinion on this (and I have multiple systems over 500GB) is to not do MPX on
this Big system, but use the multiple data streams.
I would make a policy with only this system in it. Keep your E:\ drive splits
the way that you have it. Allow only one job per policy. Create a storage
unit for this policy that does not do MPX, single drive. Point the policy to
this storage unit (set the proper volume pool). You will get multiple jobs
queued, but only one running at a time. This will ease (probably improve ) you
disk thrashing on the SCSI array.
There are many people that would have many different solutions, but it is up to
you to make the final judgment.
You can try different schemes and see which provides you with the best
performance in both Backups and Restores.
Bobby Williams
Sr. Systems Engineer
4250-A Benton Drive
Chattanooga, Tennessee 37406
Pager: 423-819-3336
Phone: 423-624-2600 x122
________________________________
From: veritas-bu-admin AT mailman.eng.auburn DOT edu on behalf of Larsen, Errin
M HMMA/IT
Sent: Tue 5/3/2005 2:26 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] Scratch Pool Usage
Hi Bobby,
Thanks for the input. I know that the E:\ drive on my client system
is a RAID-5 volume within a 2GB/sec Fibre attached Array. I understand
what you're saying about the user throughput going way down if I perform
multiple jobs against the same drive. This backup is set to run, for
that reason, at very off hours (like, 2 am Sunday morning).
The problem I'm trying to solve with all these queries is the
extremely long backup run time. This policy, on it's full schedule,
runs over 20 hours. I can't have that. I have 40+ other servers that
day that need to backup and this one policy hogs the one tape drive for
way too long. I'm trying to shorten that run time. I understand that
the MPX backups can cause a much slower restore, but getting this backup
completed in a reasonable amount of time is a higher priority for us at
this time.
Can you explain what you meant with the following:
"
> If you are going to do MPX, then it makes no sense (actually
> negates the effort) to back up a single system to an MPX
> backup tape multiple times.
"
What do you mean by, "... A single system to an MPX backup tape
multiple times."?
--Errin Larsen
> -----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
> Bobby Williams
> Sent: Tuesday, May 03, 2005 12:18 PM
> To: Paul Keating; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Scratch Pool Usage
>
>
> Word of caution on this issue. (Paul is correct, this is
> about what the end result is going to be).
>
> I don't know what type of storage array your E: drive is on
> or how big the Client server is, but you are getting ready to
> suck to life out of the server.
>
> If policy were to run (and it should after you perform Paul's
> advice), the E drive will have 4 concurrent backups running
> off of it at the same time.
>
> Now if you are on an EMC SAN array, then okay. If you are
> on a SCSI attached cabinet on a single controller, then
> expect users to scream at you.
>
> Not knowing the disk structure of the client system can get
> you into trouble quickly.
>
> You can set your policy to allow multiple data streams, but
> limit the jobs per policy to only 1. This will break the E
> drive into smaller chunks of backups. You will get a higher
> success rate on getting the most data to the tape drives.
>
> Also, (and it is a pet peeve of mine) MPX backups may seem to
> be running quicker, but we back up to do restores. MPX
> restores are doggedly slow. Also, a non-MPXed backup can be
> tarred off of a tape with gnu-tar. An MPX tape has to use
> NetBackup for a restore.
>
> If you are going to do MPX, then it makes no sense (actually
> negates the effort) to back up a single system to an MPX
> backup tape multiple times.
>
> Bobby Williams
> Sr. Systems Engineer
> 4250-A Benton Drive
> Chattanooga, Tennessee 37406
> Pager: 423-819-3336
> Phone: 423-624-2600 x122
>
>
> ________________________________
>
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu on behalf of
> Paul Keating
> Sent: Tue 5/3/2005 12:34 PM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Scratch Pool Usage
>
>
>
> Did you set the "max mpx per drive" option in the Storage Unit config?
>
> Paul
>
> > -----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 Larsen,
> > Errin M HMMA/IT
> > Sent: May 3, 2005 12:33 PM
> > To: veritas-bu AT mailman.eng.auburn DOT edu
> > Subject: RE: [Veritas-bu] Scratch Pool Usage
> >
> >
> >
> > Hi again,
> >
> > Ok, I set up my policy/schedule as follows:
> >
> > Allow multiple Data streams = yes
> > Limit Jobs Per Policy = 8
> > Media Multiplexing = 4
> >
> > I set up the Backup Selections as follows:
> >
> > NEW_STREAM
> > D:\
> > NEW_STREAM
> > E:\Directory1
> > NEW_STREAM
> > E:\Directory2
> > NEW_STREAM
> > E:\Directory3
> > NEW_STREAM
> > E:\Directory4
> >
> > I kicked off the policy. I expected to see 5 jobs, 4 of
> which would
> > go to 1 tape drive, the last going to a second tape drive.
> However,
> > when the jobs ran, NetBackup mounted 5 tapes and sent each
> job to it's
> > own Tape drive. What did I do wrong?
> >
> > --Errin
> >
> >
> > > -----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
> > > Larsen, Errin M HMMA/IT
> > > Sent: Tuesday, May 03, 2005 10:53 AM
> > > To: veritas-bu AT mailman.eng.auburn DOT edu
> > > Subject: RE: [Veritas-bu] Scratch Pool Usage
> > >
> > >
> > > Thanks again, Paul,
> > >
> > > To answer some of your questions:
> > >
> > > The NICs are foced. There ARE two of them. 2 GB nics teamed
> > > together (before you ask, yes, I checked, the drivers are
> > the latest)
> > >
> > > My backup selection list CURRENTLY looks like this: D:\, E:\
> > >
> > > The E drive is where the majority of the data sits: about
> 700 GB.
> > > The D:\ drive is much smaller, maybe 40-50 GB. They are separate
> > > physical drives. The E drive lives on a SAN, where it is
> a RAID 5
> > > configured volume.
> > >
> > > The tape drives are IBM Ultrium LTO drives, fiber attached to the
> > > NetBackup Master Server. I have 8 of these in a Sun
> > Branded L180.
> > >
> > > I have a hard time imagining that the slow down is in the
> client's
> > > SAN connection to the target drives, or the Master Server's SAN
> > > connection to the Tape Drives.
> > >
> > > Thanks in advance for the help.
> > >
> > > --Errin
> > >
> > >
> > >
> > > > -----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 Paul
> > > > Keating
> > > > Sent: Tuesday, May 03, 2005 10:12 AM
> > > > To: veritas-bu AT mailman.eng.auburn DOT edu
> > > > Subject: RE: [Veritas-bu] Scratch Pool Usage
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks for the response, Paul.
> > > >
> > > > No prob
> > > >
> > > > > I have a policy (MS-Windows-NT) that takes Diff-Inc
> > > backups every
> > > > > day except Sunday, which is when it takes a full.
> This produces
> > > > > one job (I was under the mistaken impression that
> Multiplexing
> > > > > allowed
> > > > one job to
> > > > > run to multiple tapes. Thanks for correcting me).
> > > >
> > > > MultiPLEXing allows multiple jobs from one or more
> machines to run
> > > > to ONE tape. Primarily for fast tape drives and
> > slow clients.
> > > >
> > > > MultiSTREAMing allows multiple jobs from one machine to run to
> > > > multiple tapes. Primarily for fast clients and slow tapes
> > > >
> > > > > That job has been
> > > > > running between 19-21 hours(!!). I need to shorten that
> > > run time.
> > > > > This is a Windows File Server. The total backup size
> is about
> > > > > 750GB. Right now the policy is configured as follows:
> > > > >
> > > > > Policy stuff:
> > > > > Limit Jobs per Policy = 4
> > > > > Allow multiple data streams = Unchecked
> > > >
> > > > This is ONE machine?
> > > > You want multiple backups jobs from one machine to go
> to multiple
> > > > drives, correct?
> > > > Eg:
> > > > C:\ to drive 1
> > > > D:\ to drive 2
> > > > Etc.
> > > >
> > > > Here is your prob. You need to check "Allow multiple
> data streams"
> > > >
> > > > And your "Backup Selections" list should look something like:
> > > > NEW_STREAM C:\ NEW_STREAM D:\ NEW_STREAM S:\
> > > >
> > > > Etc......
> > > > If your drives are not different physical disks,
> however, this may
> > > > actually hurt performance. You only want to pull maximum of 1
> > > > stream per physical disk.
> > > >
> > > > >
> > > > > Schedule Stuff:
> > > > > Type = Full Backup
> > > > > Media Multiplexing = 4
> > > >
> > > > Another prob. Set multiplexing to 1. (setting multiplex to 4
> > > > allows 4 backup jobs to go to one tape.)
> > > >
> > > > >
> > > > >
> > > > > Any suggestions on shorting the backup time? Any more
> > > info I can
> > > > > provide?
> > > >
> > > >
> > > > What type of tape drive?
> > > > Gig or Fast Ethernet?
> > > > Are NICs forced or set to auto Negotiate?
> > > >
> > > > That's a lot of data, if you're not prepared for it... I'm
> > > > currently backing up approximately that much data,
> split between 2
> > > > win2k3 clusters. Each cluster has a RAID5 diskset with
> about 1TB
> > > > of space available. Each machine has a GigE NIC dedicated to
> > > > backups. (separate VLAN from production networrk traffic) I'm
> > > > pulling 2 streams (different
> > > > driveletters) from each RAID5 diskset, (only due to logical
> > > > naming) then multiplexing the two streams onto a single LTO2
> > > > tapedrive, getting about 50 Mbytes/sec per tape.
> > > >
> > > > We had some significant issue getting these machines up to
> > > > speed.......Antivirus was a HUGE speed killer.
> > > >
> > > > Paul
> > > >
> > > > _______________________________________________
> > > > 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
> >
> >
>
> _______________________________________________
> 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
|
