About delay in detecting of loss of connection (WSFC and VCS on Windows)
There may be a delay in the detection of the loss of a connection from a NetBackup Windows master server to a media server. For example, consider that a media server goes down while running a backup. There may be a delay on the master server before it detects that the media server is no longer available. It may first appear that a problem exists with the NetBackup Windows master server. This delay is a result of a certain TCP/IP configuration parameter on Windows called KeepAliveTime. By default, this parameter is set to 7,200,000 (two hours, in milliseconds). More information about the KeepAliveTime and other associated TCP/IP configuration parameters on Windows may be found in the following Microsoft knowledge base articles: Q140325 and Q120642.
Because of the delay jobs appear to be active on that media server even after the connection to the media server has gone down. In some cases an undesirable delay can occur before the current backup job fails. NetBackup tries to retry the job on a different media server, if one is available.
This delay is especially noticeable when the media server in question is a NetBackup failover media server that runs in a Windows Server Failover Clustering (WSFC) environment. NetBackup relies upon the NetBackup master server to restart the NetBackup jobs that were running on the NetBackup failover media server when a failover occurs.
You may want to modify the configuration parameter on the NetBackup Windows master server. However, exercise extreme caution. The parameter is a system-wide parameter that affects all TCP/IP communications for that system. Also, it may be advantageous to modify this parameter on Windows media servers that use the failover master server.