Re: [BackupPC-users] Bizarre form of cpool corruption.

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