Re: [BackupPC-users] BackupPC_verifyPool mismatchs found - what to do?

[Holger P. <wb...@pa...>]

Hi,

Matthias Meyer wrote on 2012-12-02 01:57:07 +0100 [[BackupPC-users] BackupPC_verifyPool mismatchs found - what to do?]:
> I've tried the BackupPC_verifyPool.pl from Holger Parplies.
> Unfortunately some MD5 errors found and print out. e.g.:
> [28878] 083212b41c2482783128c9212f1f8a26     (        78) != 70f6bdb839eed7efdfe8f8b01f4dcbc7
> 
> Did I have a problem?

if there are no other indications, not necessarily. While this is not
*supposed* to happen, there used to be a bug in BackupPC that caused top-level
attrib files for backups with more than one share to be linked into the pool
with an incorrect pool file name. The only adverse effect was that the (small
amount of) space for the attrib file was not shared between backups. I'm not
sure when this bug was fixed. Perhaps Jeffrey can provide you with more detail
- he's the one that debugged the problem. The indicated file size (78 bytes)
seems plausible for a top-level attrib file, so this may well be what you are
seeing.

> What should/can I do?

Investigate whether this is the case. If not, look at the files in question.
See below.

> How to find out which file it is?

The above file is cpool/0/8/3/083212b41c2482783128c9212f1f8a26 (or pool/... if
you used the -u switch). Which file(s) in the pc/ tree this links to is more
difficult to determine. First of all, for the problem I mentioned above, my
understanding is that the link count of the pool file should be 2 (one pool
link, one attrib file link; after that the pool file will never be re-used,
because it will never match, as it has a name not matching its contents). If
the link count is *not* 2, this seems to be an indication that the contents
changed on disk when they in no case should have, which is Not Good(tm).

>From the pool file ('ls -i cpool/0/8/3/083212b41c2482783128c9212f1f8a26') you
can determine the inode and search for that in the pc/ tree. Assuming this is
a top-level attrib file, you can speed things up greatly by not traversing the
backups. Depending on the number of hosts and backups, you might get away with
something as simple (though not necessarily as fast as you might expect) as
'ls -i1 pc/*/*/attrib | sort > /tmp/top-level-attrib-inums'. Search the output
file for the inode numbers you determined.

If it's not top-level attrib files, you're looking at something like
'find pc/ -inum ... -ls', which will take *long*. You'll probably want to at
least look for all inodes in one traversal, which is probably easier to code
in Perl than type into one find invocation ;-).

In any case, you can look at the contents using just the pool file name and
BackupPC_zcat. That might give you enough information to be able to locate the
file.
For attrib files, BackupPC_zcat produces output that is not very human
readable, though it *does* contain the file names (meaning share names, in the
case of a top-level attrib file), so it might be good enough. I'm not sure
whether BackupPC_attribPrint will work with the pool file name, but you could
try that as well.

Hope that helps.

Regards,
Holger