I run BackupPc on a Debian Squeeze server. It backups other Debian Squeeze machines on my LAN succesfully. I've setup it to backup another Debian Squeeze machine on Wan, but the backup always fails with the error message:

Aborting backup up after signal PIPE
Got fatal error during xfer (aborted by signal=PIPE)

The backup is executed via ssh, and the configuration of this backup client is:

$Conf{RsyncArgs} = [
        # Do not edit these!
        # If you are using a patched client rsync that supports the
        # --checksum-seed option (see http://backuppc.sourceforge.net),
        # then uncomment this to enabled rsync checksum cachcing
        # Add additional arguments here
$Conf{FullPeriod} = 6.97;
$Conf{IncrPeriod} = 0.49;
$Conf{FullKeepCnt} = 4;
$Conf{IncrKeepCnt} = 93;
$Conf{XferMethod} = 'rsync';
$Conf{RsyncShareName} = '/';
$Conf{BackupFilesExclude} = [
$Conf{XferLogLevel} = 1;
$Conf{CompressLevel} = 9;
$Conf{PingMaxMsec} = 200;
$Conf{ClientTimeout} = 3600*8;          # 6 Hours!!

I tried a local tar backup to see if there is some issue woth the filesystem, and everything gone fine.

Any suggestions on how to debug ?

  • more info needed. Like, how are you backing up ? I'm assuming over ssh ?
    – Sirex
    Jan 11, 2012 at 14:24
  • An excerpt of the config would probably be very helpful for us.
    – Tim
    Jan 11, 2012 at 14:38
  • I've edited the original question. Yes, rsync over ssh. The config file is now in the question. Thank you !
    – GabrieleV
    Jan 11, 2012 at 15:12

5 Answers 5


I've invesitgate on the meaning of sigpipe. As described in SIGPIPE - Wikipedia, the free encyclopedia:

On POSIX-compliant platforms, SIGPIPE is the signal sent to a process when it attempts to write to a pipe without a process connected to the other end. ...

So I suspected that the trouble was with the ssh transport that gets disconnected.

I've setup a longer timeout to ssh using the options -o ServerAliveInterval=300, in the config:

$Conf{RsyncClientCmd} = '$sshPath -o ServerAliveInterval=300 -q -x -l root $host
 $rsyncPath $argList+';

Now the backup has complete successfully!

  • I had a similar error and I googled and came this page. I also use rsync method and in configuration file I do not have $Conf{RsyncClientCmd} variable. Where(main conf file or client conf file) should I provide the above statement? Dec 3, 2012 at 12:05
  • In client conf file if you want to apply this modification only to a specific client. In main conf, if you want this behavior applied globally.
    – GabrieleV
    Dec 4, 2012 at 19:12
  • It doesn't work on my installation. BackupPC 3.3.0 Jun 28, 2013 at 12:44
  • I had the same error message after deleting a directory listed as to be backed up from the filesystem and not updating the backup list in backuppc FWIW.
    – jopasserat
    Apr 24, 2017 at 19:27

Just in case this is useful to others, we were getting both aborted by signal=PIPE and Child exited prematurely on some backups (only incremental backups it would seem). Adjusting the $Conf(RsyncClientCmd) didn't work for our installation of BackupPc 3.1 on Centos 5 (soon to be upgraded), as it broke the attempt to connect in the first place. We are using rsync over ssh.

As the machine was dedicated to doing backups and we were concerned about others using ssh access, we simply set ClientAliveInterval=300 in /etc/ssh/sshd_conf on the client machines (not the BackupPc server), but this could have been done for the individual login instead.


I got this message when running backups with BackupPC just because the RsyncShareName parameter (that defines which folders should be synced) was not correct: the given folder didn't exist on the server.

You could check at this parameter in the Xfer settings.


I got the same issue and I finally figured it out. When you define host specific directories to back up for a host and one of these directories does not exist, rsync will fail with message like:

Got fatal error during xfer (aborted by signal=PIPE)

After removing the directory everything works perfectly without any additional rights on rsync.

Hope my experience will help you guys.


There was some changes in the course of BackupPC version 3.X that was incompatible with rsync 3.2.3

See https://github.com/backuppc/backuppc/issues/369

We had the same problem and solved it by adding --protocol=28 in the main configuration (Xfer) with the RsyncArgs parameter.

Alternatively, you can also edit the config.pl with the following:

$Conf{RsyncArgs} = [

(only the last line is important, you might want to keep the rest unchanged)

Then if you have Ubuntu clients, you might want to check with the following arguments:

$Conf{RsyncArgsExtra} = [

on their respective <name_of_host>.pl files

For Debian 10 (Buster) servers, you only need to have --noatime in their specific config (RsyncArgsExtra)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .