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