Я запускаю BackupPc на сервере Debian Squeeze. Он успешно выполняет резервное копирование других машин Debian Squeeze в моей локальной сети. Я настроил его для резервного копирования другой машины Debian Squeeze в Wan, но резервное копирование всегда завершается ошибкой:
Aborting backup up after signal PIPE
Got fatal error during xfer (aborted by signal=PIPE)
Резервное копирование выполняется через ssh, и конфигурация этого клиента резервного копирования:
$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!!
Я попробовал создать локальную резервную копию tar, чтобы увидеть, есть ли какие-либо проблемы с файловой системой, и все прошло нормально.
Есть предложения по отладке?
Я исследовал значение sigpipe. Как описано в SIGPIPE - Википедия, бесплатная энциклопедия:
На платформах, совместимых с POSIX, SIGPIPE - это сигнал, отправляемый процессу, когда он пытается выполнить запись в канал без процесса, подключенного к другому концу. ...
Поэтому я подозревал, что проблема была в ssh транспорт, который отключается.
Я установил более длительный тайм-аут, чтобы ssh используя параметры -o ServerAliveInterval=300, в конфиге:
$Conf{RsyncClientCmd} = '$sshPath -o ServerAliveInterval=300 -q -x -l root $host
$rsyncPath $argList+';
Теперь резервное копирование успешно завершено!
На всякий случай, если это будет полезно для других, мы получили оба aborted by signal=PIPE и Child exited prematurely на некоторых резервных копиях (казалось бы, только инкрементные). Регулировка $Conf(RsyncClientCmd) не работал для нашей установки BackupPc 3.1 на Centos 5 (скоро будет обновлено), так как это в первую очередь сорвало попытку подключения. Мы используем rsync над ssh.
Поскольку машина была предназначена для резервного копирования, и мы беспокоились о других, использующих ssh-доступ, мы просто установили ClientAliveInterval=300 в /etc/ssh/sshd_conf на клиентских машинах (не на сервере BackupPc), но вместо этого это можно было бы сделать для индивидуального входа в систему.
Я получил это сообщение при выполнении резервного копирования с помощью BackupPC только потому, что RsyncShareName параметр (который определяет, какие папки следует синхронизировать) был неверным: данная папка не существовала на сервере.
Вы можете проверить этот параметр в Xfer настройки.
У меня такая же проблема, и я, наконец, понял ее. Когда вы определяете каталоги для конкретного хоста для резервного копирования для хоста, а один из этих каталогов не существует, rsync завершится ошибкой с сообщением вроде:
Got fatal error during xfer (aborted by signal=PIPE)
После удаления каталога все работает без дополнительных прав на rsync.
Надеюсь, мой опыт поможет вам, ребята.