Eu tenho um script de backup rsync para transferir dados entre dois servidores Ubuntu (localizados em diferentes países). Os dados que estão sendo armazenados em backup são muito grandes em termos de número de arquivos. É aproximadamente 17GB no tamanho totalmente. O script é executado no servidor receptor . Então, é basicamente um pull . Autenticação de chave pública-privada usada para login.
O script funciona bem; o backup vem acontecendo com sucesso há muitos meses.
Ultimamente, nos últimos 6 dias, os backups não foram concluídos. O processo de rsync é executado por cerca de 45 minutos ou mais. E então acaba. Eu não tenho ideia do porquê de parar. Do que eu posso ver, ele nem sequer conclui a construção e a verificação da lista de arquivos. Eu tenho a saída cron direcionada para um arquivo de log. No log, tudo que vejo é: receiving file list ... done . Mas eu posso ver que nada foi transferido para o destino de backup.
Se eu executar o script manualmente, após cerca de 45 minutos, só vejo isso: ./sync.sh: line 51: 9078 Killed $RSYNC $OPTIONS $SOURCE $DESTINATION
Como e onde vejo o motivo da falha? Como sei qual servidor está realmente matando o processo, o remetente ou o destinatário?
A máquina pull (onde o script é executado) é uma caixa low-end . É uma VM KVM com 256MB de RAM. Então, eu estou querendo saber se o edifício da estrutura de arquivos está ocupando muita memória RAM, causando assim um erro OOM. Mas como eu verifico se este é o caso? Além disso, não houve aumento significativo de arquivos para causar uma falha súbita.
Alguma dica seria apreciada.
Obrigado.
Atualização 1
Como sugerido por @APZ, adicionei mais alguns sinalizadores verbosos (3 no total) e executei o script manualmente, redirecionando a saída para um arquivo. Aqui está a saída no final:
(.... lots of file names....)
received 5795917 names
done
recv_file_list done
get_local_name count=5795917 /storage/ <======== Reached here after about 40 minutes. Was stuck here for about 10 minutes or so.
[Receiver] _exit_cleanup(code=14, file=main.c, line=788): about to call exit(14)
rsync: fork failed in do_recv: Cannot allocate memory (12)
rsync error: error in IPC code (code 14) at main.c(788) [Receiver=3.0.9]
Para responder @TimHaegele, até onde eu sei, o host da VM (Prometeus / IperWeb) não faz nenhuma limitação de CPU, IO ou qualquer coisa. Eu poderia perguntar a eles, no entanto. Eles são extremamente bem avaliados.
Minha instalação do Ubuntu na VM tem 512 MB de swap configurados. Talvez eu possa aumentar isso para dizer 2 GB ou mais? O espaço em disco não é um problema.
Quando o rsync está em execução, esta é a saída de free -m :
total used free shared buffers cached
Mem: 239 236 2 0 0 3
-/+ buffers/cache: 232 7
Swap: 511 510 1
Com base nessa evidência, ainda faria diferença alterar as configurações do Daemon do SSH, conforme sugerido?
Atualização 2
O consenso parece ser que pouca memória é o problema. Então, eu adicionei um novo arquivo de swap de 2GB e o ativei. Então, agora eu tenho um total de 2,5 GB de swap.
Depois, executei o script novamente (manualmente). Desta vez, durou mais de 90 minutos. Estava transferindo os arquivos até esse momento. Mas então, de repente, o processo desistiu. Nos logs, vejo que terminou com o seguinte erro:
Invalid packet at end of run (4330026) [sender]
[generator] _exit_cleanup(code=12, file=io.c, line=1532): about to call exit(12)
rsync error: protocol incompatibility (code 2) at main.c(695) [sender=3.0.7]
rsync: writefd_unbuffered failed to write 23 bytes to socket [generator]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1532) [generator=3.0.9]
[receiver] _exit_cleanup(code=19, file=main.c, line=1316): about to call exit(19)
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]
Como você pode ver, a máquina do remetente tem 3.0.7 e o receptor (extrator) possui 3.0.9. Eu não entendi bem qual é o erro.
Enquanto isso, vi o comentário do @ APZ e modifiquei meu script para substituir --delete-after por --delete-delay . Eu estou correndo novamente agora. Voltarei com atualizações.
Atualização 3
Adicionando mais troca e usando --delete-delay em vez de --delete-after parece ter feito o truque. O cron job regular parece estar funcionando corretamente também.
Além disso, eu segui este artigo para fazer o rsync rodar com o sudo na máquina de envio. Isso também removeu os avisos Permission denied (13) durante a transferência.
Obrigado pela ajuda, todos.
P.S .: Todos os que participaram neste Q & A deram sugestões úteis. Infelizmente, só posso marcar uma resposta correta.