7.6.0.1 - Windows 2012 - status 13 after 2h

[dokhook]

Hi,

I have a problem with Windows 2012 netbackup 7.6.0.1 client (fileshare cluster) backup via media Win 2012 7.6.0.1 server.

Client and media server are Hyper-V machines running on the same hypervisor. No firewall between.

Policy type: MS-Windows

Storage: Basic disk - on media server - actually NAS attached and mounted on media server

Take check points every 5 min

Jobs per policy: 1

We treid both with Perform snapshot backups and without...

Each time we tried to make a full backup it ended up with status 13 after 2h.

bpbkar log on client side show this:

An Exception of type [SocketWriteException] has occured at:

  Module: @(#) $Source: src/ncf/tfi/lib/TransporterRemote.cpp,v $ $Revision: 1.55 $ , Function: TransporterRemote::write[2](), Line: 338

  Module: @(#) $Source: src/ncf/tfi/lib/Packer.cpp,v $ $Revision: 1.91 $ , Function: Packer::getBuffer(), Line: 652

  Module: tar_tfi::getBuffer, Function: D:\NB\NB_7.6.0.1\src\cl\clientpc\util\tar_tfi.cpp, Line: 311

  Local Address: [::]:0

  Remote Address: [::]:0

  OS Error: 10054 (An existing connection was forcibly closed by the remote host.

Solutions that we tried to use in this case are based on recommendations from:

http://www.symantec.com/business/support/index?page=content&id=TECH7963

http://www.symantec.com/business/support/index?page=content&id=TECH6127

We tried: running backups in different time, turned offload settings on NICs and hyper-v switch, changed timeout settings on client/server side, compared NIC drivers verions on other Win2012 hyperv servers (the same version), checked event logs on server (no record), restart client server,media server, switched to different hyper-v node, swithced client to different node (fileshare cluster)

Finally we found a way around by creating two separate policys - that take less than 2h each to finish up. That’s working.

What timeout setting could cause network timeout after 2h?

What could possibly cause this issue?

[Michael_G_Ander]

Does the event logs on the client show any errors at that time ? there have been issues with dll versions before which showed up as eventid 100 or 1000

Think the Windows tcp have a default timeout of 2 hours for idle connections

Regards

Michael

[Marianne]

We need to see entire bpbkar log, all text in Job details as well as bpbrm log on media server. Copy logs to .txt files and upload as file attachments. Always a good idea to break down large volume on a file server into multiple streams, allow multiple jobs in policy and ensure max jobs per client is more than 1. Same effect as multiple policies.

[Deb_Wilmot]

hmmm - check for firewalls.  They typically have a two hour timeout.

[dokhook]

Hm... Something is causing timeout. Right now I've found a way-around by splitting this backup into 2 policies - so they finish before that timeout. 

Problem still exists though.