BackupPc fails with SIGPIPE

Question

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!
            '--numeric-ids',
            '--perms',
            '--owner',
            '--group',
            '--devices',
            '--links',
            '--times',
            '--block-size=2048',
            '--recursive',
        #
        # 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
        #
        '--checksum-seed=32761',
        #
        # Add additional arguments here
        #
        '-D',
        '--one-file-system',
];
$Conf{FullPeriod} = 6.97;
$Conf{IncrPeriod} = 0.49;
$Conf{FullKeepCnt} = 4;
$Conf{IncrKeepCnt} = 93;
$Conf{XferMethod} = 'rsync';
$Conf{RsyncShareName} = '/';
$Conf{BackupFilesExclude} = [
        '/cdrom',
        '/dev',
        '/files/_nobackup',
        '/floppy',
        '/lost+found',
        '/mnt',
        '/proc',
        '/sys',
        '/tmp/ssh-*',
        '/var/lib/amavis/amavisd.sock',
        '/var/lib/backuppc',
        '/var/lib/nagios3/rw/nagios.cmd',
        '/var/run/acpid.socket',
        '/var/run/clamav/clamd.ctl',
        '/var/run/courier/authdaemon/socket',
        '/var/run/mysqld/mysqld.sock',
        '/var/run/nut/usbhid-ups-apc_backups_cs500',
        '/var/run/proftpd.sock',
        '/var/run/screen',
        '/var/spool/postfix/private/amavis',
        '/var/spool/postfix/private/anvil',
        '/var/spool/postfix/private/bounce',
        '/var/spool/postfix/private/bsmtp',
        '/var/spool/postfix/private/defer',
        '/var/spool/postfix/private/discard',
        '/var/spool/postfix/private/error',
        '/var/spool/postfix/private/ifmail',
        '/var/spool/postfix/private/lmtp',
        '/var/spool/postfix/private/local',
        '/var/spool/postfix/private/maildrop',
        '/var/spool/postfix/private/odmr',
        '/var/spool/postfix/private/proxymap',
        '/var/spool/postfix/private/relay',
        '/var/spool/postfix/private/retry',
        '/var/spool/postfix/private/rewrite',
        '/var/spool/postfix/private/scache',
        '/var/spool/postfix/private/scalemail-backend',
        '/var/spool/postfix/private/smtp',
        '/var/spool/postfix/private/tlsmgr',
        '/var/spool/postfix/private/trace',
        '/var/spool/postfix/private/uucp',
        '/var/spool/postfix/private/verify',
        '/var/spool/postfix/private/virtual',
        '/var/spool/postfix/public/cleanup',
        '/var/spool/postfix/public/flush',
        '/var/spool/postfix/public/pickup',
        '/var/spool/postfix/public/qmgr',
        '/var/spool/postfix/public/showq',
        '/var/spool/postfix/var/run/saslauthd/mux',
        '/var/spool/squid',
];
$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 ?

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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} = [
  '--numeric-ids',
  '--perms',
  '--owner',
  '--group',
  '-D',
  '--links',
  '--hard-links',
  '--times',
  '--block-size=2048',
  '--recursive',
  '--protocol=28'
];

(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} = [
  '--open-noatime',
  '--no-msgs2stderr'
];

on their respective <name_of_host>.pl files

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