Backup Central

Hi,

Jeffrey J. Kosowsky wrote on 2011-10-06 19:28:38 -0400 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed)?cpool files - WEIRD BUG]:
Holger Parplies wrote at about 17:54:05 +0200 on Thursday, October 6, 2011:
[...]
Actually, what I would propose [...] would be to
test for pool files that decompress to zero length. [...]

Actually this could be made even faster since there seem to be 2
cases:
1. Files of length 8 bytes with first byte = 78 [no rsync checksums]
2. Files of length 57 bytes with first byte = d7 [rsync checksums]

So, all you need to do is to stat the size and then test the
first-byte

I'm surprised that that isn't faster by orders of magnitude. Running both
BackupPC_verifyPool and the modified version which does exactly this in
parallel, it's only about 3 times as fast (faster, though, when traversing
directories currently in cache). An additionally running 'find' does report
some 57-byte files, but they don't seem to decompress to "". Let's see how
this continues. I still haven't found a single zero-length file in my pool
so far (BackupPC_verifyPool at 3/6/*, above check at 2/0/*).

Regards,
Holger

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

On Thu, Oct 6, 2011 at 8:06 PM, Timothy J Massey <tmassey < at > obscorp.com ([email]tmassey < at > obscorp.com[/email])> wrote:
Redundancy is a good thing.

(While we're on the subject, I've considered Les' argument that compressed files take less space on the disk and are therefore less likely to be corrupted before.  It's true, but like dedupe errors, it's just *one* possible failure--and to me, not a very likely one.  It's not one worth defending against by *itself*.  Having uncompressed files makes, e.g., scanning a badly scrambled filesystem for salvagable data *much* easier.
I've seen orders of magnitude more media errors then filesystem errors.  In fact I can barely recall a filesystem error that was a big problem for fsck to fix - well except for one case that was really caused by bad RAM where the file contents would also have been randomly bad.


 When it comes to backup, I will almost *always* choose simple over fancy, even if fancy gives me other advantages but not additional safety.)


Simple to me means that the result fits on one disk which I can raid-mirror, split, and keep several extra snapshot copies. Compression makes that a lot easier.  And I'd probably go back to an earlier copy instead of groveling through the live one in the unlikely scenario that the filesystem fails.  Plus, it covers the case of a building disaster with one of the copies offsite.

--
  Les Mikesell
     lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

Holger Parplies wrote at about 02:45:56 +0200 on Friday, October 7, 2011:
Hi,

Jeffrey J. Kosowsky wrote on 2011-10-06 19:28:38 -0400 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed)?cpool files - WEIRD BUG]:
Holger Parplies wrote at about 17:54:05 +0200 on Thursday, October 6, 2011:
[...]
Actually, what I would propose [...] would be to
test for pool files that decompress to zero length. [...]

Actually this could be made even faster since there seem to be 2
cases:
1. Files of length 8 bytes with first byte = 78 [no rsync checksums]
2. Files of length 57 bytes with first byte = d7 [rsync checksums]

So, all you need to do is to stat the size and then test the
first-byte

I'm surprised that that isn't faster by orders of magnitude. Running both
BackupPC_verifyPool and the modified version which does exactly this in
parallel, it's only about 3 times as fast (faster, though, when traversing
directories currently in cache). An additionally running 'find' does report
some 57-byte files, but they don't seem to decompress to "". Let's see how
this continues. I still haven't found a single zero-length file in my pool
so far (BackupPC_verifyPool at 3/6/*, above check at 2/0/*).


Do those 57 byte files have rsync checksums or are they just
compressed files that happen to be 57 bytes long?

Given that the rsync checksums have both block and file checksums,
it's hard to believe that a 57 byte file including rsync checksums
would have much if any data. Even with no blocks of data, you have:
- 0xb3 separator (1 byte)
- File digest which is 2 copies of the full 16 byte MD4 digest (32 bytes)
- Digest info consisting of block size, checksum seed, length of the block digest and the magic number (16 bytes)

The above total 49 bytes which is exactly the delta between a 57 byte
empty compressed file with rsync checksums and an 8 byte empty
compressed file without rsync checksums. The common 8 bytes is
presumably the zlib header (which I think is 2 bytes) and the trailer
which would then be 6 bytes.

Note: If you have any data, then you would have 20 bytes (consisting a 4 byte
Adler32 and 16byte MD4 digest) for each block of data.


------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Hi,

Jeffrey J. Kosowsky wrote on 2011-10-06 22:09:52 -0400 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
Holger Parplies wrote at about 02:45:56 +0200 on Friday, October 7, 2011:
Jeffrey J. Kosowsky wrote on 2011-10-06 19:28:38 -0400 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed)?cpool files - WEIRD BUG]:

Actually this could be made even faster since there seem to be 2
cases:
1. Files of length 8 bytes with first byte = 78 [no rsync checksums]
2. Files of length 57 bytes with first byte = d7 [rsync checksums]

So, all you need to do is to stat the size and then test the
first-byte
[...]
An additionally running 'find' does report some 57-byte files, but they
don't seem to decompress to "".

Do those 57 byte files have rsync checksums or are they just
compressed files that happen to be 57 bytes long?

well, I implemented your suggestion quoted above to determine whether they
would decompress empty, so they are just compressed files that happen to be 57
bytes long. Actually, I included a debug option to output 57 byte files
with a first byte \x78, and they seem to show up there (I didn't check if all
do, I was only interested in checking my implementation).

My point was that 'find cpool \( -size 8c -o -size 57c \)' does show quite a
number of hits - so many that it's hard to see whether there are any 8-byte
files in between - and the 57-byte ones are pointless, because you'd have to
individually determine whether they are just compressed files that happen to
be 57 bytes long or empty compressed files with checksums. I simply hadn't
expected that. 'find cpool -size 8c' should still be useful as a lightweight
check for your first case.

Given that the rsync checksums have both block and file checksums,
it's hard to believe that a 57 byte file including rsync checksums
would have much if any data.

I thought you were positive that it can't. Actually, your reasoning seems to
say that it can't, but what about an 8-byte file without checksums? There's
not much point in looking for 8-byte files with a \x78 if it's uncertain that
they're really empty - at least we'd need to decompress to check.

Regards,
Holger

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

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?

Also: can you give a better resolution on the mod times, i.e. which one is
older?

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?

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?

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?

So far, *none* of my 1.1 million pool files (875000 checked so far) seem to be
empty. I'm using a different BackupPC version (2.1.2), but others seem to be
checking their pools, too. I'd still like to know whether this has happened
*anywhere* else, and if yes, what those BackupPC setups have in common with
yours.

Regards,
Holger

P.S.: If anyone wants a copy of the "quick" pool check - I've named it
BackupPC_jeffrey for lack of a better idea - please ask. It's mainly
a modified copy of BackupPC_verifyPool, hacked together in a few
minutes. I *have* used "open FILE, '<', ...", so I'm fairly sure I'm
not clobbering all 57-byte-files in the pool, but I can't say I did
much testing, and I was already tired when writing it, so you might
prefer to wait a day . I might even add IO::Dirent support ...

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Hi,

I wrote on 2011-10-07 05:46:36 +0200 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
[...]
So far, *none* of my 1.1 million pool files (875000 checked so far) seem to be
empty.

1148398 files in 4096 directories checked, 0 zero-length with, 0 without
checksums.

(according to your suggestions - 8 byte \x78 and 57 byte \xd7). Check took
about 4 hours including interruptions (suspended for about 45 minutes for
BackupPC_nightly, among others).

Regards,
Holger

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

On Friday 07 October 2011 01:41:45 Holger Parplies wrote:
Hi,

Les Mikesell wrote on 2011-10-06 18:17:06 -0500 [Re: [BackupPC-users] Bad
md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
On Thu, Oct 6, 2011 at 5:21 PM, Arnold Krille <arnold < at > arnoldarts.de>
wrote:
No, it makes perfect sense for backuppc where the point is to keep
as much history as possible online in a given space.

No, the point of backup is to be able to *restore* as much historical
data as possible. Keeping the data is not the important part.
Restoring it is. Anything that is between storing data and
*restoring* that data is in the way of that job.

Actually the point of a backup is to restore the most recent version of
<something> from just before the trouble (whatever that might be).

Yes, but throw in the fact that it may take some unpredictable amount
of time after the 'trouble' (which could have been accidentally
deleting a rarely used file) before anyone notices and you see why you
need some history available to restore from the version just before
the trouble.

I think you've all got it wrong. The real *point* of a backup is ...
whatever the person doing the backup wants it for. For some people that
might just be being able to say, "hey, we did all we could to preserve the
data as long as legally required - too bad it didn't work out".

No, that case of archiving documents and communications to fulfill legal
requirements is called an _archive_! And while such a thing works well on
paper (and for paper-documents, provided you are good friends with the
archive-lady), try to access any old electronic n a company after they
switched from lotus to SAP in between. Still the data is archived according to
the law.

Usually, it
seems to be sufficient that the data is stored, but some of us really *do*
want to be able to *restore* it, too, while others are doing backups mainly
for watching the progress. Fine. That's what the flexibility of BackupPC is
for, right?

No one wants a backup. Everyone only wants restore.

Good thing backuppc can do backups that don't get in your way, restore that
works simply by clicking in a web-interface and additionally write complete
dumps to archive-media...

Have fun,

Arnold

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

On Thu, 2011-10-06 at 17:54 +0200, Holger Parplies wrote:

To be honest, I would *hope* that only you had these issues and everyone
else's backups are fine, i.e. that your hardware and not the BackupPC software
was the trigger (though it would probably need some sort of software bug to
come up with the exact symptoms).

So far my scan of one of my systems has finished and has given:

758080 files in 4096 directories checked, 0 had wrong digests, of these
0 zero-length.

Another system is currently up to a/f/d of a full scan and has found the following errors

tim < at > carbon:~$ grep -v ok /tmp/pool-check.txt ; tail -n 1 /tmp/pool-check.txt
[335403] 1ef2238fe0d1e5ffb7abe1696a32ae91 ( 384) != 5c6bec8866797c63a7fbdc92f8678c1f
[397563] 2429be9ee43ac9c7d0cb8f0f4f759cd8 ( 364) != 12351030008ccf626abd83090c0e5efa
[761269] 452017085ec5f0a21b272dac9cbaf51c ( 2801) != b4f9ab837e47574f145289faddc38ca2
[1260873] 72ed33567c8fbda29d63ade20f13778d ( 364) != 8521efc754784ac13db47545edb22fcd
[1380912] 7d264e0aedb7d6693946594b583643d6 ( 270) != c15a891ef0ab8d4842196fcbaf3e6b9f
[1534431] 8a7e659dd6d0a4f45464cc3f55372323 ( 5 != de0ac1b424d9a022b4f3415896817ec4
[1598997] 90097fdb369c0152e737c7b88c0f6ff6 ( 282) != 16d682e1c10bee80844e6966eaabbbcf
[1873732] a9d171972fca12bf03c082b7fba542d1 ( 364) != ee42dab9abc3486325a674779beaabcc
[1940164] afd73ec3463ea92cfd509ead19f938f5 ( 5102) ok

Once the scan has finished I'll do a bit more digging about when the
files where created and from which host I'm backing up.

The hardware in both cases is the same, a HP Microserver with a a raid5
disk set.

The one without errors is running Fedora 15 32bit but with a pool that
has been moved from Ubuntu 10.04 32bit a few months ago, the pool dates
from the 20/09/2010.

The one with errors has always been on current Ubuntu 32bit, the pool
dates back to 08/01/2010.

--
Tim Fletcher <tim < at > night-shade.org.uk>


------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Hi,

Tim Fletcher wrote on 2011-10-07 10:21:29 +0100 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
[...]
Another system is currently up to a/f/d of a full scan and has found the following errors

tim < at > carbon:~$ grep -v ok /tmp/pool-check.txt ; tail -n 1 /tmp/pool-check.txt

you might be better off with terse progress output (-p) instead of verbose
(-v), though that doesn't combine well with logging. I should add a logging
option to just output the mismatches to a file.

[335403] 1ef2238fe0d1e5ffb7abe1696a32ae91 ( 384) != 5c6bec8866797c63a7fbdc92f8678c1f

In case that needs explanation, the output format is

[counter] file-name (uncompressed-file-length) != computed-hash

Normally, file-name and hash match (except for a possible _n suffix of the
file-name in case of a hash collision). These lines indicate for which files
that is not true, and what hash chain they should really be in (though no
attempt is made to fix that, and you should only do so yourself if you know
what you are doing). The "(uncompressed-file-length)" was added yesterday and
breaks 80 character output width. Sorry.

[761269] 452017085ec5f0a21b272dac9cbaf51c ( 2801) != b4f9ab837e47574f145289faddc38ca2

My mismatches all have an uncompressed file length between 64 bytes and 163
bytes. I haven't checked, but that does seem to fit well with the known
top-level-attrib-file-bug fixed in BackupPC 3.2.0.
2801 bytes does sound rather long for a top-level attrib file, unless you have
many shares with long names . You might want to check what the file
uncompresses to with something like

sudo .../BackupPC_zcat $TopDir/cpool/4/5/2/452017085ec5f0a21b272dac9cbaf51c | less

A top-level attrib file would include the share names and a lot of control
characters.

If the mismatches are only top-level attrib files, there's not much point in
investigating any further (or worrying about it - the data should be ok). If
they're not, there definitely is.

The one without errors is running Fedora 15 32bit but with a pool that
has been moved from Ubuntu 10.04 32bit a few months ago, the pool dates
from the 20/09/2010.

My guess would be that either that pool was created and used with BackupPC
3.2.0 or newer, or that you only have a single share for each host that is
backed up.

The one with errors has always been on current Ubuntu 32bit, the pool
dates back to 08/01/2010.

This would seem to be an older pool (started pre 3.2.0 - which makes sense,
because 3.2.0 hadn't been released yet . Switching to 3.2.0 would not have
*corrected* the errors, but only prevented new ones from appearing.

Regards,
Holger

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Hi,

Jeffrey J. Kosowsky wrote on 2011-10-07 01:08:03 -0400 [Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
Holger Parplies wrote at about 05:46:36 +0200 on Friday, October 7, 2011:
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]:
[...]
Why would PoolWrite.pm change the mod time of a pool file that is not
in the actual backup?

ok, so by now we seem to have concluded that Xfer::Rsync *might* modify a file
in a previous backup. Without looking at the code, it's just speculation, and
I haven't currently got the time, considering the code is quite complex.

After some reflection, it *does* make sense to add checksums to a file in a
previous backup, even if the file is found to have changed in the current
backup, because the *previous* backup may still be the reference for a future
backup (also, the pool file might be reused).

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

Strange time zone on #110 .
15 seconds seems to be *ages*, considering we're talking about small files
(right?). I agree with you: 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.

Meaning they corresponded to the backup times?

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

I had thought the same (2nd backup - for the 3rd they should be present and
give a speedup). This is another thing we could check - which files in our
backups have checksum caches. What makes *me* wonder is that this still only
seems to happen to you.

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.

Or, put differently: no.

If the file *has* rsync checksums, they wouldn't have been added on the first
backup. mtime says they were added by #110, thus the file would have been in
the pool without checksums then. Or would it have been the *reference file* at
the time checksums were added!?

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?

No, we don't really know what the situation was then. We're trying to
reconstruct it from evidence, which we are having a hard time interpreting
(at least I am).

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?

Use the force, read the source. I don't think it's *meant* to clobber the data
portion.

Maybe it's something with rsync checksum caching/seeding when it tries
to add a checksum?

There does seem to be a connection, though there are those 8-byte files
*without* checksum cache. Are these failed attempts of some sort, or are they
- like you first said - an indication that it's *not* checksum caching?

I'm just guessing here...

So am I.

Regards,
Holger

------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

On Fri, 2011-10-07 at 10:21 +0100, Tim Fletcher wrote:

Another system is currently up to a/f/d of a full scan and has found the following errors

The final answer off the server with the larger and older install of
backuppc is:

2836949 files in 4096 directories checked, 13 had wrong digests, of
these 0 zero-length.

What sort of information would be helpful for follow up?

--
Tim Fletcher <tim < at > night-shade.org.uk>


------------------------------------------------------------------------------
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.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/