☰

A transferência Rsync via SSH é muito lenta

tag-icon • tag-icon backup rsync
A transferência Rsync via SSH é muito lenta

Estou fazendo um backup remoto do meu site. O catálogo inteiro tem cerca de 70 GB, com cerca de 5.000.000 de arquivos no total. Aqui está o comando que executo no meu servidor de backup:

rsync -ah -e ssh --delete --link-dest=/backups/2013.09.06 [email protected]:/var/www/backups/2013.09.07

O processo é executado por mais de 48 horas e simplesmente trava.

Executei strace -po processo rsync no cliente (servidor web onde o site está localizado) e vi que esse processo para periodicamente no selectcomando, terminando = 0 (Timeout)depois de algum tempo e depois continua.

open("mysite/files/1694201", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10083, ...}) = 0
read(3, "\r\n\320\224\320\265\321\201\321\217\321\202\321\214 \320\273\320\265\321\202, \321\210\320\265\321\201\321\202\321"..., 10083) = 10083
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999998})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\320\260\320\262\320\260\320\271\321\202\320\265...\320\232\320\270\320\264\320\260\320\271\321\202\320\265 \320\274"..., 4092) = 4092
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 0 (Timeout)

O processo fica suspenso na última linha por cerca de um minuto.

Por que isso pode estar acontecendo? Por que o processo demora tanto e nunca chega ao fim? O que aqueles 0 (Timeout)em situação poderiam significar?

Ambos os servidores executam o rsync 3.0.9, o IO não está sobrecarregado.

Responder1

O que esses 0 (Timeout) no strace poderiam significar?

Leia o 5º parâmetropassou para selecionar.

Claramente, o rsync (por si só) não é apropriado para o método que você escolheu para fazer backup dos arquivos. Ele precisa gerar um hash para cada um dos 5 milhões de arquivos e enviá-lo pela rede apenas para descobrir se alguma coisa mudou.

Se fosse eu, encerraria tudo em um script em execução no servidor de origem que

  1. Verifica a hora (tstart) em que a sincronização anterior bem-sucedida foi iniciada

  2. Encontra todos os arquivos na fonte que possuem mtime > tstart

  3. rsync esses arquivos modificados para o servidor de backup

por exemplo

#!/bin/bash

touch newrun
find /var/www -newer lastrun -exec rsync ....
rm -f lastrun
mv newrun lastrun

Responder2

você tem certeza de que tem 5 bilhões de arquivos?

Eu prefiro tgz e rsync que tgz, já que a comparação inicial de src com dst levaria uma eternidade se você tivesse HDs um tanto "normais", sem SAN ou SSD de alta velocidade.

onde seu processo é lento? durante a transferência de arquivos ou durante o src<->dst inicial - check?(enviando lista de arquivos incrementais ...)

Eu verificaria IOWAIT nas duas pontas, se possível. e, se as máquinas tiverem md-raid, cat /proc/mdstatus. um desempenho io muito ruim pode ser resultado de um ataque de reconstrução (mas muito improvável).

e eu faria uma transferência com um único arquivo grande --progressativado durante a transferência de rsync para verificar a velocidade da rede.

dicas de depuração(você deve testar cada gargalo possível, apenas para ter certeza: esse NÃO é o problema)

  • tente rsync com -avzh --progress --stats
  • desempenho io localmente
  • desempenho de rede
  • hd/raid-status (SMART), verifique se há hardware defeituoso

informação relacionada