Large Backup Question

Andrew21210

ADSM.ORG Member
Joined
Apr 10, 2008
Messages
97
Reaction score
2
Points
0
PREDATAR Control23

We are backing up several large SQL flat file .bak, .trn and .diff files on a nightly basis. Approximately 2.3 TB. This takes 12-14 hours to complete. I have been looking for possible solutions to speed this backup time and I may have stumbled across something but I wanted to get some expert input.

TSM Server version is 5.5.6 and the client is a Windows 2003 cluster. Our TCPWINDOWSIZE is set to 131,072 on the TSM server and 128 on the client (although that only affects restores/retrieves). The client does NOT have TCP Windows Scaling enabled in the OS so therefore defaults to 64k. The Windows 2003 operating system CAN leverage TCP Windows Scaling but it must be manually enabled via a registry edit.

So my question is this: If I get the Windows OS group to enable TCP Windows Scaling, should I see a positive performance bump for this backup?
 
PREDATAR Control23

Before you adjust for windows scaling, are backups backing up to disk first? What is your resource utilization set for? How fast is your network?

Answers to these may or may not need adjusting for windows scaling.
 
Last edited:
PREDATAR Control23

Before you adjust for windows scaling, are backup backing up to disk first? What is you resource utilization set for? How fast is you network?

Answers to these may or may not need adjusting for windows scaling.


We are backing up to VTL on a 1 GB network. Resource utilization is set to 10 on the client.
 
PREDATAR Control23

Maximum mount points allowed is 8, however, we almost never see all eight being used.
 
PREDATAR Control23

Maximum mount points allowed is 8, however, we almost never see all eight being used.

One other way you can speed things up is by off loading the backup to disk first before dumping to VTL. This is an expensive solution for most companies but it will sure speed up things. I have setups like this that practically cut the backup time to disk by more than 60%. However, my setup was dedicated for the environment and all tuned to give maximum throughput.

Offload to tape - real or VTL - is another story :(
 
PREDATAR Control23

One other way you can speed things up is by off loading the backup to disk first before dumping to VTL. This is an expensive solution for most companies but it will sure speed up things. I have setups like this that practically cut the backup time to disk by more than 60%. However, my setup was dedicated for the environment and all tuned to give maximum throughput.

Offload to tape - real or VTL - is another story :(

Interestingly, we are making a change this week so that we can back this client up to disk and then offload to tape. Unfortunately, our disk subsystem is low tier SATA so we'll see how it works out. Our backup time may actually get slower....
 
Top