FloydATC
ADSM.ORG Member
Exchange 2010 with 2 HUBCAS servers + 2 DB servers, each running in Windows 2008 R2. HUBCAS servers have 2 virtual CPUs and 12 GBytes RAM, DB servers have 8 virtual CPUs and 32 GBytes RAM. VMware ESXi 5.1 with 2 out of 15 hosts practically dedicated to Exchange during weekends. (Each host has 12 cores and 256 Gbytes RAM)
26 databases, total of 970 Gbytes, distributed 50/50 but all backed up on one DB server*
No FCM or other fancy tricks.
Running TDP version 6.3.0.2 and BA version 6.3.0.14
Full backup starts on fridays at 17:00 and doesn't finish until 03:00-06:00 on monday morning. That's about 60 hours, or just over 16 Gbytes per hour. Gigabit network with very little utilization, TSM server is on the same IP subnet so there's no L3 routing or firewalling involved.
TSM server running version 6.3.3.200 is specced with dual quad core xeon and 32 Gbytes RAM. The TSM database is just over 150 Gbytes and is on SSD. STGpools are on disk, RAID6 with a total of 48 SATA drives minus spares, connected via FC. The TSM server also backs up just under 150 clients, but those are incremental only and finish well within their 2 hour nightly window, to STGpools on another disk system.
I have a hard time seeing where the bottleneck is. All servers and network components are monitored and show no congestions/utilization spikes. I have tried tuning the TCP options in TDP without seeing any real improvement. (Difference is within 2-3 hours)
The exact command used to run the full backup is
Config files are shown below.
My question is this: Would it be a good idea to try running the 26 backups in paralell rather than sequentially? I'm thinking something along the lines of 26 concurrent TDP sessions, each doing one database. Or 13 sessions, each doing two databases. I imagine I would have to increase the resourceutilization on the client and mountpoints on the server, but are there any obvious problems with such an approach?
*) Yes, I have considered running the backup on both DB servers, this might cut the backup time in half but the current setup means if one DB server fails, backup on the other DB server can be activated by simply changing a Windows service from "disabled" to "automatic". If we have to rely on both servers to run the backup then we would no longer have a redundant setup. Sort of. It's not that we absolutely can't, but I would prefer not to.
tdpexc.cfg:
dsm.opt:
26 databases, total of 970 Gbytes, distributed 50/50 but all backed up on one DB server*
No FCM or other fancy tricks.
Running TDP version 6.3.0.2 and BA version 6.3.0.14
Full backup starts on fridays at 17:00 and doesn't finish until 03:00-06:00 on monday morning. That's about 60 hours, or just over 16 Gbytes per hour. Gigabit network with very little utilization, TSM server is on the same IP subnet so there's no L3 routing or firewalling involved.
TSM server running version 6.3.3.200 is specced with dual quad core xeon and 32 Gbytes RAM. The TSM database is just over 150 Gbytes and is on SSD. STGpools are on disk, RAID6 with a total of 48 SATA drives minus spares, connected via FC. The TSM server also backs up just under 150 clients, but those are incremental only and finish well within their 2 hour nightly window, to STGpools on another disk system.
I have a hard time seeing where the bottleneck is. All servers and network components are monitored and show no congestions/utilization spikes. I have tried tuning the TCP options in TDP without seeing any real improvement. (Difference is within 2-3 hours)
The exact command used to run the full backup is
Code:
tdpexcc backup * full /skipintegritycheck /tsmoptfile=dsm.opt /logfile=excsch.log
My question is this: Would it be a good idea to try running the 26 backups in paralell rather than sequentially? I'm thinking something along the lines of 26 concurrent TDP sessions, each doing one database. Or 13 sessions, each doing two databases. I imagine I would have to increase the resourceutilization on the client and mountpoints on the server, but are there any obvious problems with such an approach?
*) Yes, I have considered running the backup on both DB servers, this might cut the backup time in half but the current setup means if one DB server fails, backup on the other DB server can be activated by simply changing a Windows service from "disabled" to "automatic". If we have to rely on both servers to run the backup then we would no longer have a redundant setup. Sort of. It's not that we absolutely can't, but I would prefer not to.
tdpexc.cfg:
Code:
LASTPRUNEDate 10/14/2013 09:48:33
MOUNTWait Yes
BACKUPMETHod VSS
TEMPLOGRestorepath D:\Restore_temp
TEMPDBRestorepath D:\Restore_temp
LOGFile tdpexc.log
LOGPrune 60
DATEformat 1
TIMEformat 1
LANGuage ENU
VSSPOLICY * * * TSM EXCHANGE
BACKUPDESTination TSM
LOCALDSMAgentnode INT-EXCHDB-01
REMOTEDSMAgentnode
dsm.opt:
Code:
NODename INT-EXCHDB-01_EXCH
CLUSTERnode no
COMPRESSIon Off
PASSWORDAccess Generate
DATEformat 1
COMMMethod TCPip
TCPPort 1500
TCPServeraddress 10.80.2.30
*TCPWindowsize 63
*TCPBuffSize 32
*TCPWindowsize 255
*TCPBuffSize 127
TCPWindowsize 2048
TCPBuffSize 512
TCPNoDelay yes
SCHEDMODE Polling
SCHEDLOGRetention 14
ERRORLOGRetention 14
MANAGEDSERVICES WEBCLIENT SCHEDULE