On Fri, Apr 23, 2010 at 12:37:58AM +1000, Tim Connors wrote:
> On Wed, 21 Apr 2010, Les Mikesell wrote:
> > On 4/21/2010 7:47 AM, Les Mikesell wrote:
> > > Philippe Bruhat (BooK) wrote:
> > >> On Wed, Apr 21, 2010 at 08:45:29AM +0200, Philippe Bruhat (BooK) wrote:
> > >> So I tried to restore that specific file using a zip archive, only to
> > >> discover that the old file on the target and the file being restored
> > >> by backuppc had the same md5 and sha1 sums.
> > >>
> > >> Is that a known bug in rsync?
> > >
> > > No - or at least I haven't heard of it. Could you have
> > > filesystem corruption on either side?
> > One other thought here: was anything else running that could have been
> > writing to or locking the file during the restore?
>
> I've seen this problem too, and it's not filesystem issues.
>
> It's either rsync or the perl library (and I very strongly suspect the
> latter) that is deadlocking. Trace it with strace - it's always the same
> place (er, sorry, can't remember offhand!). I'm restoring with rsync
> version 3.0.6 and 3.0.7.
>
> I've found that rsync restore to a filesystem that is already populated is
> so unreliable I just avoid it now. I restore to an empty path, then
> rsync from that location back to the final destination.
>
> I *once* had a backup lockup in the same fashion (only to get interuppted
> with SIGARLM about 26 hours later from memory). Repeatedly, with
> incremental backups, always locking up on the same file (this was an
> incremental of about level 3 or so, with 1 and 2 obviously having
> succeeded). I think I had it configured with full backups every 60 days,
> incrementals every day with levels 1,2,3,4,5,2,3,4,5,3,4,5,4,5 repeating.
I have seen this often (every couple of months on some host) as
well. Forcing a full has always cleared it for me.
> But the restores failing in this way is scary. And it makes me nervous to
> replace our existing backup infrastructure with backuppc if it can't
> reliably do a restore!
I use tar for the restore exclusively (and test the restore processes
using tar as well). Rsync restores don't really buy you much in a
total failure senario, tar is much faster to dump across an ssh
pipeline than the equivalent restore using rsync (2-4x IIRC).
Rsync restores are a good idea if you have a few scattered files to
restore and no command line access since it is easily initiated from
the gui. So for non-admin restores rsync is a good thing.
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
------------------------------------------------------------------------------
_______________________________________________
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/
|
