LAN FlashBackup daily Incremental job now failing, however weekly Full job runs fine

[Rodders78]

Hi

This has got me very confused:-

I have a Win2003 server client which was re-configured a while ago with a FlashBackup policy due to the number of small files contained on two of its drives.  The D: & E: drives were (flash)backing up successfully for some time, but now aren't - as far as i know there haven't been any NB config changes to have casued this, and other flashbackup jobs/policies are continuing to work.

The odd thing is that the weekly Full flashbackup job is continuing to work fine, its only the daily Incremental flashbackup job that is failing.

Can anyone point me in the right direction to start troubleshooting this please..?

I have already restarted all master/media servers and the client itself.  (Master/Media servers are running on Windows 2012R2, NB 7.6.1.1, the client also has 7.6.1.1 installed)

Kind regards

Rodders

[Rodders78]

I forgot to post the actual error:-

19/11/2015 12:56:52 - Error bpbrm(pid=8616) socket read failed, An existing connection was forcibly closed by the remote host.  (10054)
19/11/2015 12:56:52 - Error bptm(pid=9720) socket operation failed - 10054 (at child.c.1304)      
19/11/2015 12:56:52 - Error bptm(pid=9720) unable to perform read from client socket, connection may have been broken 
19/11/2015 12:56:59 - Error bpbrm(pid=8616) could not send server status message       
19/11/2015 12:57:03 - Info bpbkar32(pid=0) done. status: 13: file read failed    

[Nicolai]

10054 is a windows socket error , there is a list at :

https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx

try increasing the CLIENT_READ_TIMEOUT in Nebackup master and media servers to 1800.

Any firewall involved in the setup ?

[Rodders78]

Thanks for your prompt reply - no, there are no firewalls involved in this environment.

Will adjusting the CLIENT_READ_TIMEOUT on the master and media servers take affect immediately if other jobs are currently running..?

Should I also adjust the client setting to 1800..?

[Rodders78 · Accepted solution]

I thought I'd attempt splitting the drives out from the policy to try and pinpoint (if any) which was causing the problem - these actions seem to have solved the problem..!  :)

First ran the policy with only the \\.\D: selection = successful

Then ran the policy with only the \\.\E: selection = successful

The policy now runs with both drives selected.  :)

I'm none the wiser why it wasn't working or what fixed it tbh, but it now seems okay - so will see what happens overnight in its scheduled backup window...

[Nicolai]

Modifying CLIENT_READTIME will take affect immediatly - for new backups.

Those already active has the "old" value.

Netbackup accelerator and/or client side deduplication is modern replacement for flashbackup.

I recommend you look into those options.

[Rodders78]

Thanks Nicolai, am I correct in thinking the accelerator/dedupe technologies rely upon disk storage..?

(I'm afraid we are still backing up to tape libraries.)

[Nicolai]

Yes you are right ,  you will need disk.

Either traditional disk as Netbackup advanced disk or MSDP or  storage based deduplication like HP B6500 or EMC Data Domain.

[Marianne]

I think part of the problem is aging OS and probably hardware as well. When last was the file systems defrag'ed? Bear in mind that an Incr backup still has to 'walk' the filesystem to find changed files.