I've been running a backuppc server (currently version 3.x) for several
years, backing up a small collection of Linux and Windows machines. 

 

I recently added a new Windows 10 machine (using rsyncd), and found that,
while full backups worked well, incrementals almost always failed.  

 

Some research here found a number of other reports of this over the years,
but I couldn't find a solution.  

 

So, here is what I found out about the situation and the workaround that I'm
currently using.  

 

Logfiles on client and server weren't very helpful (even at high log
levels).  They indicated that the Windows system thought the connection had
dropped and so the rsync.exe task terminated.  Then some 20 minutes later
the server detected that the client had gone so it terminated. 

 

Running a packet trace with WireShark was more informative.  It showed the
Windows client getting transmission timeouts and retransmitting; then after
5 retransmits terminating the connection.  An interesting thing I noticed
was that the timeout interval was quite short... about 300msec.  It turns
out that Windows tunes the timeout based on the observed response on the
connection.  In this case, at the start of the rsync operation there are
many short fast interactions, then the server bogs down as it does the delta
copies of a large file. The client sending the changed blocks seems to get
too far ahead and eventually the timeouts occur.  (It is probably
significant that this new machine with the problem is much faster than any I
was previously backing up; in fact faster than the server.) 

 

There doesn't seem to be any way in Windows to set a minimum transmit
timeout (you can just set the initial value, which isn't helpful here).  But
I found that by setting(*) the maximum retries to 15 instead of the default
5, the incremental backups succeed.  

 

This isn't an ideal fix.  It's a global change so means the Windows system
is slow detecting "real" connection failures.  And of course there is a lot
of unnecessary retransmission using up network bandwidth, though this is not
a big concern in my case.  

 

I thought it might be possible to add an extra layer of buffering in the
server to keep it responsive on the connection, though this might not be
practical for really large files. Or maybe some higher level flow control to
throttle the sender. Or perhaps the network adapter parameters on either
client or server could be tweaked to address the issue.

 

I would appreciate any thoughts on better solutions.  

 

I don't know if BackupPC 4.x has the same issue.  Installing and testing
that is one of my next projects  .

 

* setting the max retries via regedit: add or change the DWORD parameter
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMa
xDataRetransmissions.

 

 

_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Reply via email to