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