From: Holger P. <wb...@pa...> - 2013-10-21 23:27:36
|
Hi, Les Mikesell wrote on 2013-10-21 16:12:34 -0500 [Re: [BackupPC-users] Repeated error on more than one client; rsync timeout]: > On Mon, Oct 21, 2013 at 3:42 PM, Hans Kraus <ha...@ha...> wrote: > > Hi, > > > > I get on more than one client the error in /var/log/syslog: "on the client" and "in /var/log/syslog" would both seem to mean that it's rsyncd reporting the error. > > ---------------------------------------------------------------- > > rsync error: timeout in data send/receive (code 30) at io.c(137) > > [sender=3.0.9] > > ---------------------------------------------------------------- > > which then leads to the backuppc error: backup failed (Child exited > > prematurely). This message would seem to mean that the child exited prematurely, not that BackupPC got an alarm signal. > > This happens for incremental and full backups. Which is a pity. You can't try simply forcing a full backup, which would otherwise be an option. > > I'm using rsyncd as transfer method. Is there any coure for that? > > Google brought up some cases with the same or similar error(s), but > > no remedy. > > I think that the ClientTimeOut setting is supposed to be for idle time > on the network connection, but under some circumstances it isn't reset > on activity and becomes the total timeout for the run. Try bumping > it much higher, especially if your current setting is approximately > the time when a timeout occurs. Nope, that's obviously not the cause. > Also rsync can have long periods of idle time reading blocks where > there are no differences from the comparison base. If the connection > goes through a NAT gateway or a stateful firewall, the devices may > time the connection out and be blocked. Well, you could look into this, but I wouldn't put too much hope into it. If I'm not totally mistaken, it's the *sender* that does most of the work, so the sender timing out sounds more like a protocol exchange problem, most probably caused by a corrupt attrib file. You could look at the XferLOG and try to find out whether the timeout always occurs at the same point. You could try checking attrib files for consistency (Jeffrey, have you got a script for that?). You could try deleting the reference backup (or perhaps moving it out of the way, though you might have to additionally patch the "backups" file) so BackupPC will use an older reference backup. That might be messy. Alternatively, you could try switching your XferMethod to 'tar', running one full backup, then switching back to 'rsyncd', and run another full backup. Just some suggestions that spring to a rather tired mind. You say you have several clients with the problem, so you could maybe test some things with a smaller or less important client. Of course, it *would* be interesting to actually trace this bug down (which would probably include examining attrib files). Which version of BackupPC are you running? Regards, Holger |