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.
|
