Hi,
Les Mikesell wrote on 2010-12-09 17:08:05 -0600 [Re: [BackupPC-users] Bizarre
form of cpool corruption.]:
> On 12/9/2010 4:44 PM, Jeffrey J. Kosowsky wrote:
> >
> > 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.
>
> I thought that was a difference between rsync/others. Rsync works
> against a previous copy making direct links to anything that already
> exists so the pool copies are only for new data. Other methods copy the
> whole file content over and don't bother looking at any earlier runs,
> just doing the hash and pool link or copy.
just to clarify:
1. Non-rsync-XferMethods never link to previous backups, only to the pool.
If new files aren't BackupPC_link-ed into the pool (which should not
happen, see below), they'll have exactly one hard link and will never
aquire more.
2. rsync *incrementals* only create entries for *changed* files. These are
linked to the pool if a matching file exists or otherwise entered into the
pool as new files (which may fail if BackupPC_link is not or incompletely
run, which should "never happen" under normal circumstances, just to be
clear).
Thus, rsync *incrementals* will never create new links to "orphaned" files.
3. rsync *full backups* create entries for *all files*. Changed files are
treated as with incrementals (i.e. linked to the pool). *Un*changed files
are linked to the same file in the reference backup. This *should normally*
be a link to a pool file, making the new entry also be linked to the pool.
If, however, it is not (and this is the case we were originally talking
about), the new entry will also not find its way into the pool. This is how
a multi-link file without pool entry can come into existance.
I believe, BackupPC *could* in fact detect this case (if the file we're
about to link to has only one link, we should try to link to the pool
instead - and possibly also correct the reference file), but I haven't
checked the source for reasons why this might not work, and I don't expect
I'll be writing a patch anytime soon :(. Also, I can't estimate if this
problem is common enough to be worth the effort (of coding and of slowing
down rsync-Xfer, if only slightly). (*)
I'm not sure what happens, if the link count of the reference file reaches
HardLinkMax - I would expect a new entry *in the pool* to be made.
4. rsync will *not* link to anything except the exact same file in the
reference backup (because it does not notice that there may be an identical
file elsewhere in the reference backup or anywhere in other backups).
Regards,
Holger
(*) Just to describe how this situation can also occur:
I knowingly introduced it into my pool when I had to start over due to
pool FS corruption and desperately *needed* a reference backup for a large
data set on the other end of a slow link. I copied the last backup from
the corrupted pool FS and ran a full backup to make sure I had intact data.
I was going to "fix the problem later" or live with the (in my case
harmless) duplication.
BTW, this is an example of "tampering with the pool" ;-).
------------------------------------------------------------------------------
_______________________________________________
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/
