Master server : solaris
Windows 2003 client is backing up with very slow speed, tried disabling the chimeny on the server using below command
netsh int tcp set global autotuning=disabled
netsh int tcp set global chimney=disabled
but still backup is running very slow.
bptestbpcd, bpclntcmd all are working fine. not sure how to troubleshoot this.
also can any one help me how to generate logs on the client side and how i can find the issue in the logs.
any key part do i have to look out for getting the error in the logs.
Can you give a little more information? things like
Network type on the client?
Amount of files/volumes on the system
There are alot of things that can influence the speed of a backup, if you have many thousands or millions of small files this can cause very slow speeds, or if the files are all very small. If the client is a 1GB connected machine with a highly utilized sql/oracle instance then the backup is competing for network.
You could always change the tuning buffer for the client, if you go to Host Properties > Clients Properties > <Client>
At the bottom under Windows Client > Client Settings > Communication Buffer Size
I usually set to 32 or 64 and work my way up.
Anothe tthing you could try is the NET_BUFFER_SZ on the client, depending on the backup type this might be helpful, but make sure its never larger than the media servers.
To create logs on the client side there should be a mklogdir.bat file in \Veritas\NetBackup\logs. Run that and it will create the logging directories for you. Also set logging to verbose 5 for the client in the host properties section of the admin console.
Out of curiosity are there any active databases running on the server you are trying to backup?
check the NIC Speed.. check whether it is 100 mbps or 1000mbps, if it is 100 mbps, change it to 1000mbps, it should be full duplex, if it is half duplex, change it to full from both switch and server, can the nic driver version, try updating it to latest, changing NIC and Duplex settings itself should work, try it
Don't start making any changes until you know where the issue is, otherwise you find the quickest way to break a system.
Disabling tcp chimney is fine though.
Enable the bpbkar log on the client (verbose 5) and the bptm log on the media server (verbose 5)
The lines containing 'waited for full buffer ' / 'bpbkar waited for empty buffer' show on which side of the backup the problem is - client side/ media server side.
I suspect it will show the client side.
Next, run a read test of the disks - eg bpbkar -nocont test.
If this is ok, run a network test.
OK, this method is not as quick as 'having a guess, getting lucky and finding the problem 1st time'
If you get unlucky, you make changes that didn't fix the problem, which in turn have introduced other problems into the environment and you end up with a very very very broken system.