Eu também encontrei isto com rsync no passado. A solução que consertou isso para mim foi executá-lo de dentro de uma sessão screen , que conseguiu 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 qualquer nome que você decida nomear a sessão, se você der um nome a ela, o que não é obrigatório). Isso irá reconectar seu shell atual a essa sessão. Lembre-se de desconectá-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 via screen no plano de fundo em uma falha, fazendo [alguém, por favor, me corrija se eu estiver errado] screen -dm 'command' . Você pode querer man screen antes de tentar o último.
EDITAR:
Estou editando minha resposta porque você confirmou que screen não oferece assistência nesse cenário, mas você respondeu ao meu comentário sugerindo que experimentasse scp e veja que tipo de resultado você obtém, ao qual você respondeu que, curiosamente, funcionou muito bem.
Então, minha nova resposta é: use scp - ou ssh (com tar ) - em vez de rsync
Concedido, scp não suporta o grande número de recursos como rsync , mas você ficaria surpreso ao descobrir quantos recursos ele suporta e que são quase < em> idêntico ao de rsync .
Cenários do mundo real para scp e outras alternativas para rsync :
Algum tempo atrás, tive a tarefa de criar um script de shell que extraísse logs de nossos servidores de produção e os armazenasse localmente em um servidor da 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 Unix instalasse rsync em nossos servidores, criei uma solução alternativa usando scp que funcionou tão bem.
Dito isso, recentemente modifiquei o script para que tudo que ele use seja ssh e tar - GNU tar / gtar , para ser exato. O GNU tar suporta muitas das opções que você realmente encontrará em rsync , como --include , --exclude , preservação de permissão / atributo, compactação, etc.
A maneira como eu faço isso agora é ssh -ing para o servidor remoto (via pubkey auth) e usando gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.] - isso grava toda a informação em stdout , que é então canalizada [localmente] para tar -xzf para que nenhuma alteração seja feita no servidor de produção remoto e todos os arquivos sejam enviados como estão para o servidor local. É uma ótima alternativa para rsync neste caso. A única coisa importante que nem o suporte tar nor scp são backups incrementais e o nível de erro em nível de bloco que verifica os recursos rsync .
O comando completo ao qual estou me referindo ao usar ssh e tar seria algo assim (o 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 oposto - tar -cf - localmente, e pipe para o servidor remoto via ssh user@remotehost "tar -xf -" - há outra resposta que referencia esse tipo de comportamento, mas não entra em tanta detalhe.
Existem algumas outras opções que incluí para acelerar as coisas. Eu cronometrei tudo implacavelmente para obter o tempo de execução o mais baixo possível. Você poderia pensar que usar compactação com tar seria inútil, mas na verdade acelera um pouco as coisas, assim como o uso do -C flag com ssh para ativar a compactação ssh também. Eu posso atualizar este post em uma data posterior para incluir o comando exato que eu uso (que é muito parecido com o que eu postei), mas eu não estou com vontade de entrar em VPN no momento, já que estou de férias esta semana.
No Solaris 10, eu também uso -c blowfish , porque é a codificação mais rápida para se autenticar e também ajuda a acelerar um pouco as coisas, mas nosso Solaris 11 não suporta ou tem esse conjunto de criptografia desativado. / p>
Além disso, se você optar por usar a opção ssh / tar , seria realmente uma boa ideia implementar minha solução original de usar screen se você estiver fazendo um backup que levará algum tempo. Caso contrário, certifique-se de que as configurações de keepalive / tempo limite no ssh_config estejam ajustadas corretamente, ou esse método também poderá causar um cano quebrado.
Mesmo que você use o scp , sempre acho que é uma prática recomendada usar screen ou tmux ao fazer uma operação desse tipo, apenas no caso . Muitas vezes eu não sigo o meu próprio conselho e não o faço, mas é de fato uma boa prática usar uma dessas ferramentas para garantir que o trabalho remoto não estrague tudo por causa de sua sessão ativa do shell sendo desconectada de alguma forma.
Eu sei que você quer descobrir a causa raiz do seu problema de rsync . No entanto, se isso for realmente importante, essas são duas ótimas soluções alternativas que você pode experimentar nesse meio tempo.