Tom
That rings a bell. These backups use VSS so you need to stagger them by 10
minutes or so to allow VSS to do its thing, and yes, you need separate logs for
each process for them to be useful but that’s just flags to the commands.
I did get a sample script from someone internal to IBM who monitors this list.
He may care to share it with you. I never implemented it because at that stage
I did not know powershell and time and projects march on, so I had to go with
what worked rather than what I would have liked.
Good luck
Steve
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Tom Alverson
Sent: Monday, 19 February 2018 1:50 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Exchange backup speed
Couldn't I just set up multiple schedulers that all start up at about the same
time to make it parallel. That way I don't need to try and extract the
errorlevels for each process and try to combine them somehow.
I tried adding a START command in front of the FULL backup at the beginning of
my batch file (to make the first FULL backup run in parallel with the
rest) but I ended up with a 418 error, and an unreadable tdpexc.log file (the
outputs from the parallel backup jobs are all mixed together often in
mid sentence). I will have to ask our storage team what they saw on their
side but in my logs I got
5060E A Tivoli Storage Manager API error has occurred.
02/18/2018 17:02:34 ANS1245E (RC122) The file has an 0n2/18/2018 17:02:34
ANS1245E (RC122) The file has an unknown format.
02/18/2018 17:13:20 ANS1236E (RC115) An unexpected error occurred.
02/18/2018 17:13:20 ACN5060E A Tivoli Storage Manager API error has occurred.
02/18/2018 17:14:05 ACN5918W The mailbox history did not update successfully on
the TSM Server.
02/18/2018 17:14:05 ACN5060E A Tivoli Storage Manager API error has occurred.
02/18/2018 17:24:30 ANS1236E (RC115) An unexpected error occurred.
02/18/2018 17:24:30 ACN5060E A Tivoli Storage Manager API error has occurred.
On Sun, Feb 18, 2018 at 4:55 PM, Harris, Steven < steven.harris AT
btfinancialgroup DOT com> wrote:
> Tom
>
> It is a failing of TSM/SP that a basic function is deemed "good
> enough" by the people who decide such things within IBM and the
> real-world implementation is left to users. Your problem is not
> uncommon and a solution should be a standard part of the marketed offering.
>
> You will need some powershell skills. Use the powershell cmdlets that
> come with TDP for Exchange and run your processes in parallel. You
> will need to code some funky error checking to make sure the correct
> return codes are returned.
>
> Regards
>
> Steve
>
> Steven Harris
> TSM Admin/Consultant
> Canberra ACT
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Tom Alverson
> Sent: Monday, 19 February 2018 6:45 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Exchange backup speed
>
> Remco:
>
> I appreciate all feedback, blunt or not. I am relatively new to TSM
> but I only work on windows client issues. A separate team works on
> the TSM storage servers and they are very experienced
>
> The servers are loafing, they have 4 cores with 32 processors, and
> 384GB of ram, not of which is anywhere near the limit. The only
> bottleneck right now is the 10GB interfaces in the exchange server and
> TSM storage servers must pass through a 1GB embedded rack switch that
> I have been urging them upgrade. If we could get anywhere near 1GB
> network throughput on the exchange backups that would be good.
>
> I'm sure the storage servers are not under stress based on performance
> of other backups we have running.
>
> On Sun, Feb 18, 2018 at 1:03 PM, Remco Post <r.post AT plcs DOT nl> wrote:
>
> > Hoi Tom,
> >
> > this might sound a bit blunt, but from what you’re asking I get the
> > strong impression that this the first time you’re working with TSM.
> > So I’m a bit anxious to give you any advise, fearing that it might
> > lead to
> more problems.
> >
> > In general with performance issues I would look into the generic
> > performance indicators of the exchange servers first. Secondly,
> > check for any network bottlenecks between the exchange server and
> > the TSM
> server.
> > Thirdly you can look into the performance indicators of your TSM server.
> > All with normal tools.
> >
> > > Op 17 feb. 2018, om 00:55 heeft Tom Alverson
> > > <tom.alverson AT GMAIL DOT COM>
> > het volgende geschreven:
> > >
> > >>
> > >>
> > >> We are trying to speed up our Exchange backups that are currently
> > >> only
> > > using about 15% of the network bandwidth. Our servers are running
> > Windows
> > > 2012R2 and Exchange 2013 CU15 with TSM 7.1.0.1 and TDPEXC 7.1.0.1.
> > > Currently we are backing up 15 DAGS per Exchange server (we have
> > > multiple exchange servers) and we are only backing up on servers
> > > that are standby replicas. Currently we are trying a 14 day
> > > schedule were we do a full backup of a different DAG per day, and
> > > incrementals on the rest. Even doing this we are having trouble
> > > completing them in 24 hours (before the next day's backup is
> > > supposed
> to start).
> > >
> > > I saw an old posting from Del saying to increase
> > > RESOURCEUTILIZATION on
> > the
> > > DSMAGENT. Does that mean the DSM.OPT in the BACLIENT folder? It
> > > was set at 2. Do either the buffers or buffrsize options make any
> difference?
> > >
> > > Also if we want to "parallelize" the backups does that mean
> > > separate scheduler services for each one? We currently use 14
> > > different batch
> > files
> > > (for the 14 days of the cycle) with something like this:
> > >
> > > [day1.bat]
> > >
> > > tdpexcc.exe backup dag1 full
> > > tdpexcc.exe backup dag2,dag3,dag4,dag5 incr tdpexcc.exe backup
> > > dag6,dag7,dag8,dag9 incr tdpexcc.exe backup
> > > dag10,dag11,dag12,dag13 incr tcpexcc.exe backup dag14,dag15 incr
> > > exit
> >
> > --
> >
> > Met vriendelijke groeten/Kind Regards,
> >
> > Remco Post
> > r.post AT plcs DOT nl
> > +31 6 248 21 622
> >
>
>
> This message and any attachment is confidential and may be privileged
> or otherwise protected from disclosure. You should immediately delete
> the message if you are not the intended recipient. If you have
> received this email by mistake please delete it from your system; you
> should not copy the message or disclose its content to anyone.
>
> This electronic communication may contain general financial product
> advice but should not be relied upon or construed as a recommendation
> of any financial product. The information has been prepared without
> taking into account your objectives, financial situation or needs. You
> should consider the Product Disclosure Statement relating to the
> financial product and consult your financial adviser before making a
> decision about whether to acquire, hold or dispose of a financial product.
>
> For further details on the financial product please go to
> http://www.bt.com.au
>
> Past performance is not a reliable indicator of future performance.
>
This message and any attachment is confidential and may be privileged or
otherwise protected from disclosure. You should immediately delete the message
if you are not the intended recipient. If you have received this email by
mistake please delete it from your system; you should not copy the message or
disclose its content to anyone.
This electronic communication may contain general financial product advice but
should not be relied upon or construed as a recommendation of any financial
product. The information has been prepared without taking into account your
objectives, financial situation or needs. You should consider the Product
Disclosure Statement relating to the financial product and consult your
financial adviser before making a decision about whether to acquire, hold or
dispose of a financial product.
For further details on the financial product please go to http://www.bt.com.au
Past performance is not a reliable indicator of future performance.
|
