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