On Wed, Apr 21, 2010 at 07:47:54AM -0500, Les Mikesell 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?
> 

Is there a way for me to run an integrity check on the backup?
I'm using the special checksum caching parameter (--checksum-seed=32761),
so if there's a way for me to check these files, or the whole backup,
I'd appreciate it.


The hard drive on the client side is brand new. I just realized that means
all the files on the target disk actually come from a previous restore.
(The original disk is completely broken.)


Back to my restore attempts...

If I completely delete the file on the client side, it is restored
correctly (that is to say, without rsync hanging). The next restore will
again hang on the same file.

I came up with the following workaround:
- watch the restore with lsof | grep rsync
- if the restore hang, I add the problematic file to my list, keep md5
  and sha1 sums for further reference, kill rsync, remove all problematic
  files, and restart the restore

During the process, I noticed that some files were restored over and over
again, but I didn't look into it further (maybe some timestamp issues?).

After redoing the restore a few times (the disk is now connected directly
to the backup server, to improve speed), I found several files with this
issue. All of them were larger than 100 Mb. So I just picked all files
bigger than 100Mb in the initially restored disk, and removed them, to
speed up the process a bit. Of course, I found a few more files that broke.
The smallest file to have issues was 67413186 bytes long.

After finally finishing the restore with a "success" status, I rechecked
the size, md5 and sha1. There were identical to the "original" values
(but, as explained in the beginning of my email, these value came from
my first restore, so it doesn't mean anything, really).


So, here's a summary:
- I had successfully restored a directory of about 8 Gb of files
- I tried to restore it again later (after losing a few files due
  to an ill considered rm)
- the subsequent restore failed, with rsync hanging indefinitely
  on some files
- removing all files over 67413186 bytes in size made the restore work
  (although I suspect the magic value is probably 64 Mb or something)

Thanks,

-- 
 Philippe Bruhat (BooK)

 When you run from your problem, you make it that much harder for good
 fortune to catch you, as well.     (Moral from Groo The Wanderer #14 (Epic))

------------------------------------------------------------------------------
_______________________________________________
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/