We currently leave our client timeouts to the default. We are looking to up the timout to eliminate any 41 errors that occur in our environment. Are there any draw backs to setting the client timeout at a much higher level on all our cleints?
It�s a global change, so yes, it can have knock on consequences if set much higher.
Worst case scenario - If the timeout is set to say 30 minutes, then when a backup (or backups) starts it will grab a tape drive, and will then attempt to perform a backup for 30 minutes. If it fails, then the tape drive will become available, but potentially that tape drive will have sat there doing nothing for 30 minutes� So it�s a case of trying it out and amending the timeout setting accordingly� Multiply this issue for the number of drives in your environment and it could consume the drives for long periods of time when they could be backing up clients which don�t suffer from the issue.
Advice is to increase the timeout gradually, but the long term fix is to sort out the cause of the timeout, which inevitably will be down to the state of the network�.
Hmm, I don't think the system grabs a tape until after the client has connected successfully; having a client that cannot connect doesn't usually take up/utilize a tape drive.
Another consideration to keep in mind with extending the timeout: depending on how long the timeout is, and how many attempts and what the retry period you are configured with are, you can have some impact on your scheduling. For example: if you have 3 attempts set and a timeout of 60 minutes, it will take ~3 hours before the job fails. Depending then on your retry period and the size of the backup window, you may not attempt another backup of that job.
Indeed, the only time it will affect your environment is if there is a major network glitch, that�s when it will affect all of the drives. A dodgy subnet on the network can also cause the problem, so it depends on how many clients you have on the affected part of the network and how many drives are assigned. You can appreciate it has more of an effect in an SSO env�.
This kind of errors are usually configuration and routing problems.
Timeout parameters aren't a permanent solution. If these errors occurs because you have a weight load on clients or servers, and you try to extend the resolution only put behind the problem.
I had this problem, and solve the situation configuring the relaunch of an error status policy every hour during the backup window. The timeout, by default 300 seconds, and the bpconfig -tries option on one.
What types of clients are getting error 41's and what types of backups are you running on these clients? The only time we really see that error in our environment is when we are running SharePoint backups and that's only because the CINC's take so long to search though a SPS V1 database. We bumped out timeout up ONLY for this reason, but it really shouldn't be needed for anything else that I can think of off top of my head. Our client read timeout currently set to 300 seconds for this reason.
also check network speed and whether or not the ports are running full or half d uplex. On Solaris determin nic speed and duplex ( you may hae to use ge or what ever if you are us ing an interface other than hme) # ndd -get /dev/hme link_mode Interpretation: 0 -- half-duplex 1 -- full-duplex