Forum Discussion
Okay - this puts a different spin on things:
ERR - Send bpfis state to CPASP-NBMSTR2 failed. status = 25
For Windows Filesystem backup, the client needs connectivity to the master.
At the end of the backup, the client needs to notify the master server that the snapshot backup is done.
If CPASP-NBMSTR2 is not the master, or if there is a connection problem on port 1556 between the client and master, the backup will hang for a long time before it actually fails.
Seems you are getting different error codes when this happens.
I have experienced this as status 156 some years ago:
https://vox.veritas.com/t5/NetBackup/Failing-backups-status-156/m-p/710476#M190301
I think that link has solved my issue.
I'm not backing up any open files so I went as far as to just outright remove the clients from that list and the error's have stopped without having to reboot the client.
Thanks for the help
- Marianne6 years agoLevel 6
WOFB is enabled by default for all MS-Windows policies.
It needs to be explicitly disabled if you don't need it.- AdamChangepoint6 years agoLevel 3
So while this did work on one client, I'm still running into the issue pretty much daily.
I've now got 5 clients with the same errors and diabling the open file backup and restarting the netbackup services will remove the BPFIS error but I'm still getting the socket read 24 errors and my only solution is a reboot of the client.
12/18/2018 10:27:36 - Critical bpbrm (pid=6432) from client : FTL - socket write failed
12/18/2018 10:27:36 - Error bptm (pid=4120) socket operation failed - 10054 (at ../child.c.1276)
12/18/2018 10:27:36 - Error bptm (pid=4120) unable to perform read from client socket, connection may have been broken
12/18/2018 10:27:36 - Error bpbrm (pid=6432) could not send server status message
- Marianne6 years agoLevel 6
Status 24 is probably the worst to troubleshoot.
The problem is that there is nothing within NBU that we can do or check to find the cause.
NBU is merely reporting the problem.
'Something' in your network or the Client's TCP stack happens to cause the drop in connection.In W2003 days, we had to disable TCP Chimney to resolve status 24.
Since W2008, the recommendation is to leave TCP Chimney enabled (but then I found another TN today that says to disable it! ).
If you type this in Google
netbackup windows status 24
you will find a bunch of TNs and forum posts.You may want to check what the NICs on problematic clients have in common.
If we ask ourselves what a reboot actually restarts/refresh in the TCP stack, it might be worth the effort looking for new firmware or drivers for NIC cards.Please also read again through the links that I posted a month ago.
Related Content
- 11 months ago
- 3 months ago
- 12 years ago
- 2 months ago