Hi,

Jeffrey J. Kosowsky wrote on 2009-08-12 18:12:09 -0400 [Re: [BackupPC-users] 
100,000+ errors in last nights backup]:
> Steve Blackwell wrote at about 14:33:54 -0400 on Wednesday, August 12, 2009:
>  > >  > > Steve Blackwell wrote at about 11:18:36 -0400 on Wednesday, August 
> 12, 2009:
>  > >  > >  > On Wed, 12 Aug 2009 10:06:37 -0400 "Jeffrey J. Kosowsky" 
> <backuppc AT kosowsky DOT org> wrote:
>  > >  > >  > > Try manually doing something like the following from the
>  > >  > >  > > command line: link
>  > >  > >  > > b32585c3cc30b7ebb556d335a08554e3 
> /media/disk/pc/steve/151/f%2f/froot/f.gconf/fdesktop/fgnome/faccessibility/fkeyboard/f%25gconf.xml
>  > >  > >  > 
>  > >  > >  > Where do I need to be to run this? 

you need to be in $TopDir/cpool/b/3/2 ... or rather, it should be

        sudo -u backuppc ln 
$TopDir/cpool/b/3/2/b32585c3cc30b7ebb556d335a08554e3 
/media/disk/pc/steve/151/f%2f/froot/f.gconf/fdesktop/fgnome/faccessibility/fkeyboard/f%25gconf.xml

(or use 'link' if you prefer). You need to get $TopDir right though. See
below.

>  > # sudo -u backuppc link
>  > b32585c3cc30b7ebb556d335a08554e3 
> /media/disk/pc/steve/151/f%2f/froot/f.gconf/fdesktop/fgnome/faccessibility/fkeyboard/f%25gconf.xml
>  > link: cannot create link
>  > 
> `/media/disk/pc/steve/151/f%2f/froot/f.gconf/fdesktop/fgnome/faccessibility/fkeyboard/f%25gconf.xml'
>  > to `b32585c3cc30b7ebb556d335a08554e3': No such file or directory

Yes, most directories won't contain a file with that name ;-).

>  > Jeffrey, I'm now thinking that two backups have somehow been scheduled
>  > at the same. See the Les Miskell thread.

I agree with that except for the name. But I don't think it's the problem, at
least not the one you're looking for. I can't imagine why two backups of the
same host would be scheduled simultaneously, and I don't think it's a good
idea to do so :-). BackupPC doesn't usually do this. Have you changed the code
in any way? Have you seen such a thing happen before?

> I don't know. I am perplexed since the code that is creating the error
> code '3' is as follows (from MakeFileLink in Lib.pm):
> 
>     return -1 if ( !-f $name );
>     for ( $i = -1 ; ; $i++ ) {
>         return -2 if ( !defined($rawFile = $bpc->MD52Path($d,
>     $compress)) );
>         $rawFile .= "_$i" if ( $i >= 0 );
>         if ( -f $rawFile ) {
>             if ( (stat(_))[3] < $bpc->{Conf}{HardLinkMax}
>                     && !compare($name, $rawFile) ) {
>                 unlink($name);
>                 return -3 if ( !link($rawFile, $name) );
> 
> 
> Now:
>       $name exists (per the test in the first line)
>       $rawFile exists (per the test in line 6)
> yet the link fails a couple of lines later.
> 
> So unless there is an incredibly precise race condition

Is there such a thing as a "precise race condition"? If it always happened in
the same order, would it even be a race condition?

> and assuming links work on your machine, the 'link' in the final line should
> succeed. It is hard to believe that there could be a repeatable race
> condition with another backup that is so precise that a file exists in
> one line and then no longer exists just a couple of simple lines of
> perl code later.

Ah, but it's not just a couple of simple lines of Perl code. Note the
'compare' call in line 8 (File::Compare::compare, if you were wondering),
which will take an arbitrary amount of time (and lead to an arbitrary number
of page faults/task switches, depending only on the size of the files).

But the point really is that between lines *9 and 10* (unlink/link) nothing
significant happens (unless unlink() always leads to a task switch, which I
doubt). Even then, $rawFile continues to -f, and deleting a link and replacing
it with a new link to the same file should succeed any number of times. Only
if interrupted *between unlink and link*, the process *might* find upon being
rescheduled that the link() fails because another process has already created
the file again.

But all of that is really beside the point. Let's take a step back. Where are
we?

We're in BackupPC_link, not in BackupPC_dump. As the log file shows (XferLOG
for host steve), the backup is apparently run twice in parallel, leading to
the failed rename (only one backup can succeed to rename 'new' to '151',
though I'm not sure what will happen to the 'backups' file). The main log file
only indicates one instance of BackupPC_link being run though (and one
instance of BackupPC will never run more than one BackupPC_link command at the
same time in any case).

So, I believe we're back to the issue of what you did wrong when moving
$TopDir. I don't remember reading which version of BackupPC you are using.
What did you do to move $TopDir? Have a look at the old location, wherever
that was. Are there files with recent modification times below the cpool/
directory? Below /media/disk/cpool? BackupPC_nightly reports files there,
but you might have copied them there at some point. If you umount /dev/sdd2,
what's below /media/disk? A cpool/ directory?

> You may also want to look at ownership/permissions
> in your pc tree to make sure that the relevant files and directories
> are writable by user backuppc.

SElinux? But why should BackupPC_dump succeed and only BackupPC_link fail?


All of this sounds rather strange. More information on your setup would
probably help clear things up. You should also avoid starting BackupPC when
$TopDir is not available (e.g. put something like
'[ -f /media/disk/.this_is_the_real_disk ] || exit 0' in your
/etc/init.d/backuppc and create the file on your disk). Making the mount point
(not the root of the file system mounted on it!) an empty directory to which
backuppc has no write permission should accomplish the same.

Regards,
Holger

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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/