Я встречался с этим и rsync
в прошлом. Решение, которое исправило это для меня, состояло в том, чтобы запустить его из screen
сеанса, что помогло поддерживать соединение с удаленным сервером.
screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session
Вы можете проверить состояние, запустив screen -x rsync
(или как вы решите назвать сеанс, если вы дадите ему имя, которое не требуется). Это повторно присоединит вашу текущую оболочку к этому сеансу. Просто не забудьте отсоединиться от него снова после того, как вы проверите состояние, чтобы он продолжал работать в фоновом режиме.
Вы также можете выполнить команду для запуска screen
в фоновом режиме одним махом, выполнив [кто-то, пожалуйста, исправьте меня, если я ошибаюсь] screen -dm 'command'
. Возможно, вы захотите, man screen
прежде чем пытаться последний.
РЕДАКТИРОВАТЬ:
Я редактирую свой ответ, потому что вы подтвердили, что он не screen
оказывает никакой помощи в этом сценарии, но вы ответили на мой комментарий, предложив попробовать scp
и посмотреть, какие результаты вы получите, на что вы ответили, что, как ни странно, все работало просто отлично.
Мой новый ответ таков: используйте scp
- или ssh
(с tar
) - вместоrsync
Конечно, scp
не поддерживает огромное количество функций , как rsync
, но вы на самом деле будете удивлены , чтобы обнаружить, сколько функций , которые он делает поддержку, которые почти идентичны , что и rsync
.
Реальные сценарии для scp
и другие альтернативы rsync
:
Некоторое время назад мне было поручено создать сценарий оболочки, который будет извлекать журналы с наших производственных серверов и сохранять их локально на веб-сервере, чтобы разработчики могли обращаться к ним в целях устранения неполадок. После неудачной попытки заставить команду Unix установить rsync
на наших серверах, я нашел обходной путь, scp
который также сработал.
При этом я недавно изменил сценарий, чтобы все, что он использует, было ssh
и tar
- GNU tar
/ gtar
, если быть точным. GNU tar
поддерживает многие параметры, которые вы фактически найдете rsync
, такие как --include
, --exclude
сохранение / сохранение атрибутов, сжатие и т. Д.
Теперь я выполняю это путем ssh
-ing к удаленному серверу (через pubkey auth) и использую gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]
- это записывает всю информацию stdout
, которая затем передается [локально], чтобы tar -xzf
на удаленном производственном сервере не было внесено никаких изменений. и все файлы вытащены как есть на локальный сервер. Это отличная альтернатива rsync
в этом случае. Единственное, что важно, ни поддержка, tar
ни scp
инкрементное резервное копирование, а также уровень проверки ошибок на уровне блоков rsync
.
Полная команда, на которую я ссылаюсь при использовании , будет примерно такой (удаленный - это Solaris 10; локальный - это Debian, хотя ssh
и tar
стоит):
cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz
В вашем сценарии это было бы наоборот - tar -cf -
локально и по каналу к удаленному серверу ssh user@remotehost "tar -xf -"
- есть другой ответ, который ссылается на этот тип поведения, но не вдавается в такие подробности.
Есть несколько других опций, которые я включил, чтобы ускорить процесс. Я неуклонно рассчитывал все, чтобы время выполнения было как можно меньше. Можно подумать, что использовать сжатие с помощью tar
будет бессмысленно, но на самом деле это немного ускоряет процесс, также как и использование -C
флага ssh
для включения ssh
сжатия. Я могу обновить этот пост позже, чтобы включить точную команду, которую я использую (которая очень похожа на ту, которую я опубликовал), но сейчас я не чувствую желания подключаться к VPN, поскольку на этой неделе я в отпуске.
В Solaris 10 я также использую -c blowfish
, потому что это самый быстрый шифр для аутентификации, а также помогает ускорить процесс, но наш Solaris 11 либо не поддерживает его, либо этот набор шифров отключен.
Кроме того, если вы решите использовать параметр ssh
/ tar
, было бы неплохо реализовать мое первоначальное решение, screen
если вы делаете резервное копирование, которое займет некоторое время. Если нет, убедитесь, что ваши настройки keepalive / timeout настроены ssh_config
правильно, иначе этот метод также может привести к поломке канала.
Даже если вы согласитесь scp
, я всегда считаю, что это лучший метод для использования screen
или tmux
при выполнении операций такого рода, на всякий случай . Много раз я не следую своему собственному совету и не могу этого сделать, но действительно полезно использовать один из этих инструментов, чтобы гарантировать, что удаленное задание не испортится из-за того, что ваш активный сеанс оболочки каким-то образом отключился.
Я знаю, что вы хотите выяснить причину вашей rsync
проблемы. Однако, если это действительно важно, это два отличных обходных пути, с которыми вы можете поэкспериментировать.
kerberos
для аутентификации на удаленном сервере.