BackupPc перестал работать с SIGPIPE
Я полагаю, что Коммутаторная соединительная линия (IST) все еще не вполне стандартизирована через поставщиков. Таким образом, столь же прохладный, как это, если все Вам нужно, дублирование через два переключателя (и не выравнивание нагрузки, т.е. ~2GB от 2 портов 1GB), можно просто использовать режим обработки отказа при предзнаменовании NICs для достижения того, что Вы хотите. Это будет более просто, я думаю, поскольку можно сделать это с любыми переключателями действительно.
В Linux это называют Активным Режимом резервного копирования и довольно легко настроить связывание использования:
активное резервное копирование или 1 Активно-резервная политика: Только одно ведомое устройство в связи активно. Другое ведомое устройство становится активным, если, и только если, активное ведомое устройство перестало работать. MAC-адрес связи внешне видим только на одном порте (сетевой адаптер), чтобы не путать переключатель.
В окнах Вы делаете это с утилитами, которые прибывают от поставщика карт. Я забываю их имена, но это может быть сделано с Broadcom и Intel.
Я исследовал значение sigpipe. Как описано в SIGPIPE - Википедия, бесплатная энциклопедия :
На платформах, совместимых с POSIX, SIGPIPE - это сигнал, отправляемый процессу. когда он пытается записать в канал без процесса, подключенного к другой конец. ...
Итак, я подозревал, что проблема связана с отсоединяющимся транспортом ssh .
Я установил более длительный тайм-аут для ssh , используя параметры ] -o ServerAliveInterval = 300 , в конфигурации:
$Conf{RsyncClientCmd} = '$sshPath -o ServerAliveInterval=300 -q -x -l root $host
$rsyncPath $argList+';
Теперь резервное копирование успешно завершено!
На всякий случай, это будет полезно другим , мы получали оба прерванных с помощью signal = PIPE и Дочерний выход преждевременно для некоторых резервных копий (казалось бы, только инкрементных резервных копий). Настройка $ 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.
Надеюсь, мой опыт вам поможет, ребята.