BackupPC-users

Re: [BackupPC-users] Repeated error on more than one client; rsync timeout

2013-10-21 19:28:59
Subject: Re: [BackupPC-users] Repeated error on more than one client; rsync timeout
From: Holger Parplies <wbppc AT parplies DOT de>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Tue, 22 Oct 2013 01:25:44 +0200
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 <hans AT hanswkraus DOT com> 
> 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

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/