Hi,
Adam Goryachev wrote on 2009-07-24 12:06:13 +1000 [Re: [BackupPC-users] Bug in
Backuppc causing unnecessary re-transfer of data with rsync]:
> > [...] It appears there is a bug in BackupPC which may lead to an
> > interrupted rsync backup [...] being marked as successful, even though
> > the log file indicates that an error was detected at some point. The
> > interrupted backup will be partial (i.e. missing files), but BackupPC
> > will treat it as if it were complete. [...]
actually, the bug is in File::RsyncP. As far as I can tell, there is no error
propagation from the child process to the parent. If the parent detects an
error, it will (hopefully ;-) mark the backup as unsuccessful (well, delete it,
for an incremental, or make it a partial, for a full, I believe). If the child
does, the error will be logged, and the parent will ignore it. I find that
somewhat surprising. I hope the attached patch fixes that (and I hope I'm not
completely mistaken about all of that ;-). It should be applied to
/usr/lib/perl5/File/RsyncP.pm (for the Debian package) or wherever your
File::RsyncP.pm lives. That patch was made relative to File::RsyncP 0.68
(actually Debian libfile-rsyncp-perl_0.68-1.1), but it applies to 0.64 with a
slight offset for the second and third hunk, and the result looks ok.
Adam, can you do me a favour and test it? I currently don't have an rsync
backup that I can afford to cause to fail (actually, I don't use File::RsyncP
0.68 anywhere either ...), and you are more familiar with the problem anyway.
I'll have to install a test BackupPC server one of these days ...
> I could probably try and reproduce it if it was helpful by killing the
> ssh connection or similar. Let me know if you need this, and also what
> extra logging you need enabled....
I'm interested in both a successful backup (no fatal error propagated from the
child if there is none) and a failing one (backup should be discarded). I
wouldn't raise the logLevel for the moment. It should be >= 1, but I believe
it is by default.
Note that killing the ssh connection *might* lead to a different result,
because the parent process could detect that too (if it were to attempt to
write to the socket). Probably, that would depend on what phase the transfer
is in.
I'm reasoning that if the child process would be erraneously "detecting" fatal
errors (and that was the reason why they're not reported), there would be
spurious "Child is aborting" messages in successful backups. I can't find any
in my log files, but that does not mean it might not happen in other
circumstances. Does anyone else know of such occurrences?
Regards,
Holger
rsyncpdiff
Description: Text document
------------------------------------------------------------------------------
_______________________________________________
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/
|
