On Mon, Apr 04, 2011 at 09:49:55PM -0400, Jeffrey J. Kosowsky wrote:
> Holger Parplies wrote at about 18:59:00 +0200 on Monday, April 4, 2011:
>  > Hi,
>  > 
>  > John Rouillard wrote on 2011-03-31 15:20:23 +0000
>  > [[BackupPC-users] BackupPC_dump hangs with: .: size
>  > doesn't match (12288 vs 17592185913344)]: 
>  > > [...]
>  > > I get a bunch of output (the share being backed up
>  > /etc on a centos 5.5. box) which ends with:
>  > > 
>  > >   attribSet: dir=f%2fetc exists
>  > >   attribSet(dir=f%2fetc, file=zshrc, size=640, placeholder=1)
>  > >   Starting file 0 (.), blkCnt=134217728, blkSize=131072, remainder=0
>  > >   .: size doesn't match (12288 vs 17592185913344)
>  > 
>  > at first glance, this would appear to be an indication
>  > of something I have been suspecting for a long time:
>  > corruption - caused by whatever - in an attrib file
>  > leading to the SIGALRM abort. If I remember correctly,
>  > someone (presumably File::RsyncP) would ordinarily try
>  > to allocate space for the file (though that doesn't
>  > seem to make sense, so I probably remember incorrectly)
>  > and either gives up when that fails or refrains from
>  > trying in the first place, because the amount is
>  > obviously insane.
>  > 
>  > The weird thing in this case is that we're seeing a
>  > directory. There is absolutely no reason (unless I am
>  > missing something) to worry about the *size* of a
>  > directory. The value is absolutely file system
>  > dependant and not even necessarily an indication of the
>  > *current* amount of entries in the directory. In any
>  > case, you restore the contents of a directory by
>  > restoring the files in it, and you (incrementally)
>  > backup a directory by determining if any files have
>  > changed or been added. The *size* of a directory will
>  > not help with that decision.
>  > 
> 
> I too don't understand why rsync would try to treat a
> directory '.'  like a file. I mean block count and block
> size aren't meaningful when rsyncing a directory (at least
> according to my understanding of the rsync algorithm).
> Could it possibly be a character encoding issue where
> there is some file (maybe with spaces, non-printable
> characters, or some non-recognized font) that rsync ends
> up seeing as '.' rather than as the true file name. For
> example, I know Windows and Linux have different concepts
> of what characters are allowed in file names and that
> cygwin tries to do its best to make sense of the
> differences but doesn't always succeed.

Perhaps, but this is a bog standard centos (redhat) 5.5 system.
 
>  > Then again, the problematic file (or attrib file entry) may or may
>  > not be the last one reported (maybe it's the first one not
>  > reported?).
> 
> I would suggest some trial-and-error.
> What if you move the directory somewhere else and try a new backup
> (using say a new machine alias)?
> Can you do a binary-search to narrow down the error?

Sadly things started working again.  However I can answer some of your
questions.

> In particular, is the problem only when doing an incremental? Does it
> work if you force a full?

No and No. After backup 293 on March 22 which completed a
level 2 incremntal successfully, the level 3 incremental
on March 23'rd failed with a sig alarm. Then the full backup
that started on the 24 failed with sigalarms till April 1.

Some of the fulls were manually forced fulls via the web
interface and one was an automatically scheduled full.

I believe the traces/debugging from my original post were all from a
full dump using BackupPC_dump.

> Does it work if you make this the first backup on a new
> machine alias?

How would that work? The last valid backup was an incremental that
would have to be turned into a full somehow right?

-- 
                                -- rouilj

John Rouillard       System Administrator
Renesys Corporation  603-244-9084 (cell)  603-643-9300 x 111

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
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/