Me he encontrado con esto rsyncen el pasado también. La solución que lo arregló para mí fue ejecutarlo desde una screensesión, lo que ayudó a mantener la conexión con el servidor remoto.
screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session
Puede verificar el estado ejecutando screen -x rsync(o lo que sea que decida nombrar la sesión si le da un nombre, que no es obligatorio). Esto volverá a adjuntar su shell actual a esa sesión. Solo recuerde desconectarse nuevamente después de haber verificado el estado para que siga ejecutándose en segundo plano.
También puede ejecutar el comando para ejecutar screenen segundo plano de una sola vez haciendo [alguien puede corregirme si estoy equivocado] screen -dm 'command'. Es posible que desee man screenantes de intentar ese último.
EDITAR:
Estoy editando mi respuesta porque has confirmado que screenno proporciona asistencia en este escenario, pero respondiste a mi comentario sugiriendo intentar scpver qué tipo de resultados obtienes, a lo que respondiste que, curiosamente, funcionó bien.
Entonces mi nueva respuesta es esta: use scp- o ssh(con tar) - en lugar dersync
Por supuesto, scpno soporta la gran cantidad de características como rsync, pero que en realidad se sorprendería al descubrir cómo muchas características que hace de soporte que son casi idénticas a la de rsync.
Escenarios del mundo real scpy otras alternativas para rsync:
Hace un tiempo, tuve la tarea de crear un script de shell que extrajera registros de nuestros servidores de producción y los almacenara localmente en un servidor web para que los desarrolladores pudieran acceder a ellos con el fin de solucionar problemas. Después de intentar sin éxito que el equipo de Unix se instale rsyncen nuestros servidores, se me ocurrió una solución alternativa scpque funcionó igual de bien.
Dicho esto, recientemente modifiqué el script para que todo lo que usa sea sshy tar- GNU tar/ gtar, para ser exactos. GNU es tarcompatible con muchas de las opciones que realmente encontrará rsync, tales como --include, --excludepreservación de permisos / atributos, compresión, etc.
La forma en que ahora lo logro es mediante sshel uso del servidor remoto (a través de pubkey auth) y el uso gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]: esto escribe toda la información en stdout, que luego se canaliza [localmente] para tar -xzfque no se realicen cambios en el servidor de producción remoto , y todos los archivos extraídos tal cual al servidor local. Es una gran alternativa para rsyncen este caso. Lo único importante, tarni el scpsoporte son las copias de seguridad incrementales y el nivel de verificación de errores a nivel de bloque que rsynccaracterísticas.
El comando completo al que me refiero cuando uso sshy tarsería algo como esto (remoto es Solaris 10; local es Debian, por lo que vale):
cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz
En su caso, sería todo lo contrario: tar -cf -localmente y canalizar a través de un servidor remoto ssh user@remotehost "tar -xf -": hay otra respuesta que hace referencia a este tipo de comportamiento pero que no entra en tantos detalles.
Hay algunas otras opciones que he incluido para acelerar las cosas. He cronometrado todo sin descanso para que el tiempo de ejecución sea lo más bajo posible. Pensaría que usar la compresión con tarsería inútil, pero en realidad acelera un poco las cosas, al igual que usar el -Cindicador con sshpara habilitar la sshcompresión también. Puedo actualizar esta publicación en una fecha posterior para incluir el comando exacto que uso (que es muy similar a lo que publiqué), pero no tengo ganas de entrar en VPN en este momento ya que estoy de vacaciones esta semana.
En Solaris 10, también lo uso -c blowfish, porque es el cifrado más rápido para autenticar y también ayuda a acelerar las cosas un poco, pero nuestro Solaris 11 no lo admite o tiene esta suite de cifrado desactivada.
Además, si elige ir con la opción ssh/ tar, en realidad sería una buena idea implementar mi solución original de usar screensi está haciendo una copia de seguridad que llevará un tiempo. De lo contrario, asegúrese de que la configuración de keepalive / timeout en su ssh_configesté ajustada a la perfección, o este método también puede causar una tubería rota.
Incluso si sigue adelante scp, siempre me parece una práctica recomendada para usar screeno tmuxcuando se realiza una operación de este tipo, por si acaso . Muchas veces no sigo mis propios consejos y no lo hago, pero de hecho es una buena práctica usar una de estas herramientas para garantizar que el trabajo remoto no se arruine debido a que su sesión de shell activa se desconecta de alguna manera.
Sé que quieres descubrir la causa raíz de tu rsyncproblema. Sin embargo, si esto es realmente importante, estas son dos grandes soluciones con las que puede experimentar mientras tanto.
kerberospara autenticar en el servidor remoto.