BackupPC хорошо работает в моей локальной сети, но у меня проблемы с резервным копированием удаленного сервера. Я использую rsync поверх ssh и увеличил максимальный пинг до 500, потому что удаленный сервер находится далеко.
Вот мой журнал ошибок (информация о пользователе и 1.2.3.4 замаскирована):
полное резервное копирование началось для каталога / Running: / usr / bin / ssh -p 2222 -q -x -l user 1.2.3.4 / usr / bin / rsync --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size = 2048 --recursive --ignore-times. /
Xfer PIDs are now 5705 Got remote protocol 30 Negotiated protocol version 28 Sent include: /home Sent include: /home/user Sent exclude: /* Sent exclude: /home/* Sent exclude: /home/user/folder1 Sent exclude: /home/user/folder2 Xfer PIDs are now 5705,5744 [ skipped 22380 lines ] Read EOF: Tried again: got 0 bytes Can't write 4 bytes to socket finish: removing in-process file home/user/site15/something/else/here/p4677545.jpg Child is aborting Done: 19205 files, 799171349 bytes Got fatal error during xfer (aborted by signal=PIPE) Backup aborted by user signal Saving this as a partial backup
Попытка ssh как пользователя backuppc на удаленный сервер работает без запроса пароля. Общий ЖУРНАЛ выглядит так:
> 2012-02-29 00:00:00 началось полное резервное копирование каталога /
> 2012-02-29 01:00:12 Прерывание резервного копирования после сигнала PIPE
> 2012-02-29 01:00:13 Получена фатальная ошибка во время xfer (прервано signal = PIPE)
> 2012-02-29 02:00:01 началось полное резервное копирование каталога /
> 2012-02-29 03:01:09 Прерывание резервного копирования после сигнала PIPE
> 2012-02-29 03:01:11 Получена фатальная ошибка во время xfer (прервано signal = PIPE)
> 2012-02-29 10:56:16 началось полное резервное копирование каталога /
> 2012-02-29 11:59:18 Прерывание резервного копирования после сигнала PIPE
> 2012-02-29 11:59:20 Получена фатальная ошибка во время xfer (прервано signal = PIPE)
> 2012-02-29 11:59:20 Сохраненный частичный дамп 0
> 2012-02-29 12:25:15 началось полное резервное копирование каталога /
> 2012-02-29 13:26:55 Прерывание резервного копирования после сигнала PIPE
> 2012-02-29 13:26:57 Получена фатальная ошибка во время xfer (прервано signal = PIPE)
> 2012-02-29 16:48:52 началось полное резервное копирование каталога /
> 29-02-2012 17:51:41 Прерывание резервного копирования после сигнала PIPE
> 2012-02-29 17:51:42 Получена фатальная ошибка во время xfer (прервано signal = PIPE)
> 2012-02-29 17:51:42 Сохранен частичный дамп 0
> 2012-02-29 18:13:27 началось полное резервное копирование каталога /
> 2012-02-29 19:15:19 Прерывание резервного копирования после сигнала PIPE
> 2012-02-29 19:15:20 Получена фатальная ошибка во время xfer (прервано signal = PIPE)
> 2012-02-29 19:15:20 Сохранен частичный дамп 0
> 2012-02-29 19:19:55 началось полное резервное копирование каталога /
Почти всегда заканчивается после 1ч 01'или 1ч02 '. Эти значения в секундах - 3660 и 3720. Может быть, они есть в какой-то опции ...? Замечания?
Спасибо
РЕДАКТИРОВАТЬ: То, что я пробовал, и не сработало: - ServerAliveInterval = 300, ServerAliveInterval = 60 - увеличен PingMaxMsec до 500 - параметры rsync --timeout и --contimeout установлены на 20 и 200 секунд (оба значения пробовали оба варианта) - удаление параметра размера блока из rsync
Ничего не получилось. Обычно он останавливается в разных файлах, независимо от их размера.
НОВОЕ РЕДАКТИРОВАНИЕ: если я вручную вхожу на этот удаленный ssh-сервер и оставляю свой терминал нетронутым на 1 ч 26, я отключаюсь. Похоже, именно по этой причине отключается и BackupPC. Есть ли способ имитировать выполнение команд внутри сеанса BackupPC ?
Вы должны проверить значение $ Conf {ClientTimeout} в вашей конфигурации и соответственно увеличьте его.
Из-за ограничений реализации BackupPC имеет мало информации о том, что происходит во время передачи более длинного файла. Чтобы мертвые переводы не оставались вечно, перевод отменяется после $Conf{ClientTimeout} секунд - если для резервного копирования какого-либо отдельного файла на удаленном сервере требуется больше времени, чем это значение, передача резервной копии будет прервана.
Если у вас или у провайдера есть брандмауэр, проверьте его session-ttl. Обычно это 3600 ... Если брандмауэр не в ваших руках, вы также можете использовать ssh с опцией сервер как упоминалось здесь: https://unix.stackexchange.com/questions/34004/how-does-tcp-keepalive-work-in-ssh backuppc может быть изменен соответствующим образом.
Вы можете попробовать вручную выполнить одну за другой команды полного резервного копирования. Каждый раз, когда вы это делаете, backuppc будет передавать разные порции данных. Как только резервное копирование завершится успешно, вы узнаете, что все ваши данные переданы.
Вы также можете использовать параметр сжатия ssh, чтобы ускорить процесс и уменьшить количество итераций.
Дополнительные инкрементные резервные копии не должны вызывать никаких проблем, поскольку они обычно намного меньше по размеру, поэтому они короче по времени, поэтому ваше соединение не прерывается.