Video Screencast Help

NetBackup Sharepoint Farm backups failing with status 13

Created: 30 Jan 2014 • Updated: 04 Feb 2014 | 4 comments
KeirL's picture
This issue has been solved. See solution.


I'm getting intermittent failures with my full SharePoint non-GRT backups.

This is SharePoint 2010 with 1 x Front end server, 1 x backupend SQL server and 4 x App servers. All the permissions appear to be ok and the GRT backups work a treat. However, the full backups of the Farm using the Microsoft SharePoint Resources:\  directive fail about 50% of the time every other attempt pretty much.

The failure error is status 13 and it only every fails when it reaches the Microsoft Sharepoint Resources:\Shared Services\Shared Services Applications\FAST Connector services\... but thien it could fail on any one of these databases and sometimes will succeed fully.

The error is a status 13 file read failed  unable to perform read from client socket, connection may have been broken.

The bpbkar on the SQL server shows <16> dtcp_read: TCP - failure: recv socket (416) (TCP 10053: Software caused connection abort)

Another thing I observe is the speed of backups when it reaches these databases drops from 50MB/s whilst it's doing the web applications down to about 1MB/s - not sure if this is normal or not.

All the sharepoint servers are virtual machines that the latest vmtools and patched netbackup client (

The NetBackup Master server is a NetBackup Appliance running as a Master\Media server running 2.5.4

From what I've read this issue has been fixed by EEBs for previous versions, but I've assumed with my versions these EEB should be part of the release now?

many thanks 

Discussion Filed Under:

Comments 4 CommentsJump to latest comment

sri vani's picture

Hello Keirl,

The below error in the bpbkar makes me suspect network issue.

(TCP 10053: Software caused connection abort)

10054 and 10054 are related to network timeout issues.

Did you verify the Client Connect/ Readtime Out Settings for Master and Media Servers .Please try the backup by increasing the client connect and read timeout values

KeirL's picture


Thanks for the reply

I'm currently running a test backup with the increased values (I've set 1800 for each). The full backup takes a couple of hours and as this is an intermittent issue I think I would need to see several consecutive successful backups before I can say it's nailed.

thanks and I'll let you know how it goes.


sri vani's picture

I some times prefer giving 3600 smiley

I totally agree Keirl...observe  couple of backups and get back to us with results

Good luck yes

KeirL's picture


This also seems to be ok now with the increased values

many thanks