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/
