Holger Parplies wrote at about 23:25:32 +0100 on Thursday, December 9, 2010:
 > Hi,

Welcome back!!! - I was beginning to miss you on the list...
 > 
 > Jeffrey J. Kosowsky wrote on 2010-12-07 13:16:32 -0500 [Re: [BackupPC-users] 
 > Bizarre form of cpool corruption.]:
 > > Robin Lee Powell wrote at about 23:46:11 -0800 on Monday, December 6, 2010:
 > >  > [...]
 > >  > So, yeah, that's really it.  They're both really there, and that's
 > >  > the right md5sum, and both the pool file and the original file have
 > >  > more than 1 hardlink count, and there's no inode match.
 > > 
 > > Robin, can you just clarify the context.
 > > Did this apparent pool corruption only occur after running
 > > BackupPC_tarPCCopy or did it occur in the course of "normal" backuppc
 > > running.
 > > 
 > > Because if the second then I can think of only 2 ways that you would
 > > have pc files with more than one link but not in the pool:
 > > 1. File system corruption
 > > 2. Something buggy with BackupPC_nightly
 > > Because files in the pc directory only get multiple links after being
 > > linked to the pool and files only unlinked from the pool using
 > > BackupPC_nightly (Craig, please correct me if I am wrong here)
 > 
 > I'm not Craig ;-), but I can think of a third possibility (meaning files may
 > get multiple links *without* being linked to the pool, providing something 
 > has
 > previously gone wrong):
 > 
 > 3. You have unlinked files in pc trees (as you described in a seperate
 >    posting - missing or incomplete BackupPC_link runs) and then run an rsync
 >    full backup. Identical files are linked *to the corresponding file in the
 >    reference backup*, not to a pool file.

Ahhhh... that of course makes sense -- for some reason I was thinking
they were "literally" linked to the pool, but for incrementals it
really couldn't be any other way than you are saying.

This also is a very logical explanation for how it can happen if the
Backuppc linking is not working.

If I recall correctly, the first time you would do a
subsequent incremental then it should all get linked back to the pool
since they are linked not copied to the pool *unless* the file is
already in the pool in which case the new backup would be linked and
the old ones would be left orphaned. Similarly, I imagine that new
fulls would leave them stranded. Either case could explain.
 
 > 4. Tampering with the pool. Just for the sake of completeness. But we don't
 >    do that, do we? ;-)
 > 
 > 
I would never write routines that touch the pool would I? :)

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