Rsync muito lento

Question

Acabei de configurar um servidor Debian para backup de PCs com Windows. No momento, estou testando vários métodos, incluindo: rsync (usando Deltacopy no Windows), SMB via Samba e scp . Atualmente, o rsync (sem SSH e sem compactação) e o scp demoram cerca de 16 minutos em LAN gigabit para uma transferência de arquivos de 9 GB. No entanto, o SMB leva apenas alguns minutos. Por que o rsync em particular é tão lento? Eu sinto que posso estar entendendo mal de onde vêm os benefícios reais do rsync, que são de transferir apenas os bits alterados. No entanto, eu ainda sinto que isso não explica a velocidade inicial de transferência lenta e devo estar fazendo algo errado.

Estou transferindo para um compartilhamento Samba na minha caixa Linux em todas as instâncias.

    

Answer 1

o problema é que o rsync usa o tempo de modificação e o tamanho de um arquivo como uma referência rápida para julgar se um arquivo foi ou não alterado. Existe uma maneira mais detalhada e precisa de verificar se os arquivos foram alterados e o rsync suporta isso também, mas se o tempo e o tamanho de modificação de um arquivo forem adiados, essas verificações "mais detalhadas" serão ignoradas e o rsync assumirá o arquivo mudou, portanto, tenta copiar todo o arquivo.

Especificamente quando em um ambiente heterogêneo (Windows + Linux, ...) e quando não estiver trabalhando em sistemas de arquivos locais (isto é, quando usando montagens / compartilhamentos SMB ou outros protocolos), há uma pequena possibilidade, que os tempos de modificação não são passou corretamente entre a fonte rsync e seu destino.

Pode muito bem acontecer que os tempos de modificação sejam arredondados ou alterados de alguma forma pelo OS e / ou pelo protocolo de rede usado e, portanto, pareçam ser diferentes (mesmo que apenas ligeiramente, mesmo se o sistema de arquivos local tiver o "correto" mtime).

Por favor, verifique se isso pode ou não ser o caso & testá-lo via linha de comando (se possível) e utilitários como "stat" (Linux) ou se forem absolutamente necessários mini-programas perl / python, que produzem o tempo de modificação exato propagado via sistema operacional e sistema de arquivos local propriedades (em última análise, ignorando quaisquer protocolos de rede como o Samba).

Exemplo de saída para o utilitário "stat" sob unix:

$ stat somefile.txt 
  File: 'somefile.txt'
  Size: 1014        Blocks: 8          IO Block: 4096   regular file
Device: 805h/2053d  Inode: 1448800     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-07-21 17:20:33.548997182 +0530
Modify: 2011-08-16 23:27:19.648480473 +0530
Change: 2011-08-16 23:27:19.648480473 +0530

Não pode ser que seus comandos rsync consumam "16 minutos" de forma consistente. Isso não faz nenhum sentido. Normalmente, os rsyncs estão ficando mais rápidos quanto menos as diferenças são antes de & depois de cada corrida. Somente scp irá levar um tempo constante toda vez que você executá-lo, dependendo do volume de cópia. Então, esse fato, além do fato de que você já descartou a compressão & criptografia (ssh) pode ser o gargalo de desempenho realmente me faz supor que pode haver algo acontecendo com as comparações de tempo de modificação.

Eu tive este caso especificamente com montagens Samba do meu Synology NAS. No entanto, seja esse o caso com você ou não, espero que você encontre a causa real do seu problema em breve.

Divirta-se.