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.har...@btfinancialgroup.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@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. >