Holger Parplies wrote at about 05:46:36 +0200 on Friday, October 7, 2011: > Hi, > > Jeffrey J. Kosowsky wrote on 2011-10-06 22:54:44 -0400 [Re: [BackupPC-users] > Bad md5sums due to zero size (uncompressed) cpool?files - WEIRD BUG]: > > OK... this is a little weird maybe... > > [...] > > On all (saved) backups, up to backup 82, the file (and the > > corresponding cpool file e/f/0/ef0bd9db744f651b9640ea170b07225a) is > > zero length decompressed. > > > > My next saved backup is #110 which is non-zero length and has the > > correct contents. This is true for all subsequent saved backups. > > [...] > > BUT WHAT IS INTERESTING is that both pool files have the same > > modification time of: 2011-04-27 03:05 > > which according to the logs is during the time at which backup #110 > > was backing up the relevant share. > > you'll hate me asking this, but: do any of your repair scripts touch the > modification time
None of them set the modification time (except the pool/pc copy script where it sets the mod time to the original mod time). But I didn't run the repair scripts during this time period and both files are modified *exactly* during the time of backup #110. > > Also: can you give a better resolution on the mod times, i.e. which one is > older? OK... #82: Modify: 2011-04-27 03:05:04.551226502 -0400 #110: Modify: 2011-04-27 03:05:19.813321479 -040 So #110 was modified 15 seconds after #82. Hmmm Note both of those files have rsync checksums. When I looked at a couple of files without the rsync checksums, the mod times differed by a day. As an aside, I noticed that when I looked at version without the rsync checksum, that the corrected version also doesn't have an rsync checksum even after having being backed up many times subsequently -- Now I thought that the rsync checksum should be added after the 2nd or 3rd time the file is read... This makes me wonder whether there is potentially an issue with the rsync checksum... > > > Why would PoolWrite.pm change the mod time of a pool file that is not > > in the actual backup? > > PoolWrite normally wouldn't, unless something is going wrong somewhere (and > it > probably wouldn't use utime() but rather open the file for writing). > > This is an rsync backup, right? Yes... > > Could it be that this backup somehow destroyed the data in the file? > > (but even so, what would cause this to happen) > > Hmm, let's see ... a bug? > > Also, the XferLOG entry for both backups #82 and #110 have the line: > > pool 644 0/0 252 > > usr/share/FlightGear/Timezone/America/Port-au-Prince > > > > But this doesn't make sense since if the new pool file was created as > > part of backup #110, shouldn't it say 'create' and not 'pool'? > > Considering the mtime, yes. If it's rsync, an *identical* file should be > 'same', if it's tar, an identical file would be 'pool'. Could this be an > indication that it wasn't BackupPC that clobbered the file? Well, it is 'rsync'... And we know BackupPC *thinks* it's a new file since it creates a new pool file chain member. But what and why did the original file get clobbered just before the then? > > > None of this makes sense to me but somehow I suspect that herein may be a > > clue to the problem... > > Xfer::Rsync opening the reference file? But what would cause it to truncate the data portion? Maybe it's something with rsync checksum caching/seeding when it tries to add a checksum? I'm just guessing here... ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/