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@VM.MARIST.EDU] On Behalf Of Tom Alverson Sent: Monday, 19 February 2018 6:45 AM To: ADSM-L@VM.MARIST.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.p...@plcs.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.alver...@gmail.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.p...@plcs.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.
