Eu já encontrei isso rsyncno passado também. A solução que o corrigiu foi executá-lo em uma screensessão, capaz de ajudar a manter a conexão com o servidor remoto.
screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session
Você pode verificar o status executando screen -x rsync(ou o que você decidir nomear a sessão, se você der um nome, que não é obrigatório). Isso reconectará seu shell atual a essa sessão. Lembre-se de desanexá-lo novamente depois de verificar o status para que ele continue sendo executado em segundo plano.
Você também pode executar o comando para executar screenem segundo plano de uma só vez, fazendo [alguém por favor me corrija se eu estiver errado] screen -dm 'command'. Você pode querer man screenantes de tentar o último.
EDITAR:
Estou editando minha resposta porque você confirmou que screennão fornece assistência nesse cenário, mas você respondeu ao meu comentário sugerindo tentar scpver que tipo de resultados você obtém, aos quais você respondeu que por incrível que pareça, funcionou bem.
Portanto, minha nova resposta é: use scp- ou ssh(com tar) - em vez dersync
Concedido, scpnão suporta o grande número de recursos como rsync, mas você realmente se surpreender ao descobrir quantos recursos que ele faz suporte que são quase idênticos ao do rsync.
Cenários do mundo real scpe outras alternativas para rsync:
Há algum tempo, fui incumbido de criar um script de shell que extraísse logs de nossos servidores de produção e os armazenasse localmente em um servidor Web, para que os desenvolvedores pudessem acessá-los para fins de solução de problemas. Depois de tentar, sem sucesso, fazer com que a equipe do Unix instalasse rsyncem nossos servidores, criei uma solução alternativa usando o scpque também funcionava.
Dito isto, modifiquei recentemente o script para que tudo o que ele usa seja sshe tar- GNU tar/ gtar, para ser exato. GNU tarsuporta muitas das opções que você vai realmente encontrar em rsync, como --include, --exclude, permissão / preservação atributo, compressão, etc.
A maneira como eu faço isso agora é sshacessando o servidor remoto (via pubkey auth) e usando gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- isso grava todas as informações em stdout, que são canalizadas [localmente] para tar -xzfque nenhuma alteração seja feita no servidor de produção remoto e todos os arquivos puxados como estão no servidor local. É uma ótima alternativa para rsync, neste caso. A única coisa importante, tarnem o scpsuporte, são backups incrementais e o nível de erro no nível de bloco que verifica esses rsyncrecursos.
O comando completo ao qual estou me referindo ao usar sshe tarseria algo assim (remoto é Solaris 10; local é Debian, pelo que vale a pena):
cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz
No seu cenário, seria o contrário - tar -cf -localmente e canalizar para o servidor remoto via ssh user@remotehost "tar -xf -"- existe outra resposta que faz referência a esse tipo de comportamento, mas não entra em muitos detalhes.
Existem algumas outras opções que incluí para acelerar as coisas. Cronometrei tudo incansavelmente para obter o tempo de execução o mais baixo possível. Você pensaria que usar a compressão com tarseria inútil, mas na verdade acelera um pouco as coisas, assim como usar o -Csinalizador with sshpara ativar a sshcompactação também. Posso atualizar esta postagem posteriormente para incluir o comando exato que uso (que é muito semelhante ao que publiquei), mas não sinto vontade de entrar na VPN no momento desde que estou de férias nesta semana.
No Solaris 10, eu também uso -c blowfish, porque é a cifra mais rápida para se autenticar e também ajuda a acelerar um pouco, mas o nosso Solaris 11 não o suporta ou tem esse conjunto de cifras desativado.
Além disso, se você optar por ir com a opção ssh/ tar, seria realmente uma boa ideia implementar minha solução original de usar screense você estiver fazendo um backup que levará algum tempo. Caso contrário, verifique se as configurações de keepalive / timeout ssh_configestão ajustadas corretamente, ou esse método também provavelmente causará um cano quebrado.
Mesmo se você continuar scp, sempre acho que é uma prática recomendada usar screenou tmuxao executar uma operação desse tipo, apenas por precaução . Muitas vezes eu não sigo o meu próprio conselho e falho em fazer isso, mas é realmente uma boa prática usar uma dessas ferramentas para garantir que o trabalho remoto não estrague por causa de sua sessão do shell ativa ser desconectada de alguma forma.
Sei que você deseja descobrir a causa raiz do seu rsyncproblema. No entanto, se isso for realmente importante, existem duas ótimas soluções alternativas que você pode experimentar enquanto isso.
kerberospara autenticar no servidor remoto.