Re: [BackupPC-users] avoidable failure?

[Holger P. <wb...@pa...>]

Hi,

Randy Barlow wrote on 12.01.2007 at 11:58:59 [Re: [BackupPC-users] avoidable failure?]:
> Cristian Tibirna wrote:
> > The file named in the error is almost always a temporary one. It is thus 
> > conceivable that the file was created before rsync's index building and was 
> > destroyed before rsync finishing the syncing. But this is only my 
> > supposition. I don't know exactly what happens.
> > [...]
> 
> Usually, temporary files are created in the /tmp or /var/tmp directories
> - - I would recommend that you add these to the excludes directory since
> they can cause problems as you have noted, and also since there is no
> advantage to backing up temporary files.  Hope this helps!

while I perfectly agree that backing up temporary files has no advantage,
the quoted case was

Cristian Tibirna wrote on 12.01.2007 at 10:13:39 [[BackupPC-users] avoidable failure?]:
> [...]
> So, once in a while, I get errors like this:
> 
> ---------
> Xfer PIDs are now 9356,9357
> [ skipped 6674 lines ]
> finish: removing in-process file 
> ctibirna-work/MEF/CVS-HEAD/GIREF/src/commun/Adaptation/.makedep
> [ skipped 39 lines ]
> Done: 15 files, 106665 bytes
> Got fatal error during xfer (aborted by signal=ALRM)
> Backup aborted by user signal
> -----------

which is an example of a temporary file that is obviously *not* located in
/tmp or /var/tmp and can't be made to be.

You can still exclude such files, as I understand it, by adding them to
$Conf{RsyncArgs} (at the end of the list). Something like

	'--exclude=.makedep',
	'--exclude=*.o',

should do the trick (modify to suit your needs). Note that adding '.makedep'
et al. to $Conf{BackupFilesExclude} will *not* work (at least not in version
2.1.1), as the code anchors relative paths to the root of the 'share'.

rsync also has a '--cvs-exclude' option, but that would probably exclude more
from your backups than you would want it to (eg. the CVS directories).


That said, 'aborted by signal=ALRM' does *not* sound like a temporary file
problem to me (though I don't know what a temporary file problem *would*
sound like). Might you simply need to increase your $Conf{ClientTimeout}? It
would make sense that your backups take longer with busy client machines
than with idle ones, after all.

Regards,
Holger