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