Hi, 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. If I remember correctly, that is. I haven't found much time for looking at the code (or list mails) in the last year, so I might be mistaken, but I'd rather contribute the thought and be corrected than wait until I find the time to verify it myself :). > If the first, then presumably something is going wrong with either > BackupPC_tarPCCopy or how it's applied... Just in case it's not obvious, BackupPC_tarPCCopy generates a tar file that can *only be meaningfully extracted* against a "similar" pool to that it was created with (files *not referenced* by the tar file may, of course, be missing or have different content - presuming you can find a usage example for that ;-). The hard links in the tar file reference pool file names for which the actual file is (somewhat "illegally", but that's really the whole point ;-) not contained in the tar file. There is thus no way for tar to know if it is actually linking to the intended file or a file with the same name but different content - it is up to you to make sure the contents are correct. You usually do that by copying the pool and running BackupPC_tarPCCopy immediately afterwards, *without BackupPC modifying the source pool in between*; you have probably stopped BackupPC altogether before starting the pool copy. BackupPC_nightly may rename pool files. If that happens after copying the pool and before running BackupPC_tarPCCopy, (some of) the links will point to the wrong file (with respect to the pool copy). That said, I can't see how that would cause the unlinked pc files Robin is observing. However, *using* a pool copy (i.e. running BackupPC on it) for which BackupPC_tarPCCopy has stored the file contents, because it could not find the pool file, would cause that file to remain "outside the pool" forever, as long as you are using rsync and don't modify the file contents, as I described above. You probably know that, but I thought I'd clarify what I expect Jeffrey means by "something going wrong with how BackupPC_tarPCCopy is applied". Oh, and of course there's always 4. Tampering with the pool. Just for the sake of completeness. But we don't do that, do we? ;-) Hope that helps. Regards, Holger ------------------------------------------------------------------------------ _______________________________________________ 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/
