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