Acelerando o rsync sobre o smb

7

Estou fazendo o backup de uma caixa do Linux em SMB para um NAS. Eu montei o NAS localmente e depois rsync muitos dados (100GB ou mais). Eu acredito que está demorando muito para fazer isso: mais de 12 horas. Eu esperava ser muito mais rápido depois que tudo fosse copiado, já que quase nada é alterado de um dia para o outro.

Existe uma maneira de acelerar isso?

Eu estava pensando que talvez o rsync pense que está trabalhando com discos rígidos locais e usa soma de verificação em vez de comparações de tempo / tamanho? Mas não encontrei uma maneira de forçar comparações de data e hora. Qualquer outra coisa que eu pudesse verificar?

    
por pupeno 24.09.2009 / 07:32

7 respostas

27

Acho que você está entendendo mal o algoritmo rsync e como a ferramenta deve ser aplicada.

A vantagem de desempenho do Rsync vem de fazer transferências delta - isto é, mover apenas os bits alterados em um arquivo. Para determinar os bits alterados, o arquivo deve ser lido pelos hosts de origem e destino e pelas somas de verificação de bloco, em comparação com os bits que são alterados. Esta é a parte "mágica" do rsync-- o próprio algoritmo rsync.

Quando você monta o volume de destino com o SMB e usa o rsync para copiar arquivos do que o Linux "vê" como uma fonte local e um destino local (ambos montados nessa máquina), a maioria das versões modernas do rsync mudam para 'arquivo inteiro' 'modo de cópia, e desligue o algoritmo de cópia delta. Isso é uma "vitória" porque, com o algoritmo delta-copy ativado, o rsync leria todo o arquivo de destino (através do fio do NAS) para determinar quais bits do arquivo foram alterados.

O "caminho certo" para usar o rsync é rodar o servidor rsync em uma máquina e o cliente rsync na outra. Cada máquina lerá arquivos de seu próprio armazenamento local (que deve ser muito rápido), concordará sobre quais bits dos arquivos foram alterados e transferirá apenas esses bits. Eles estão usando quantidades rsync de um 'cp' falsificado. Você poderia realizar a mesma coisa com 'cp' e provavelmente seria mais rápido.

Se o seu dispositivo NAS suportar a execução de um servidor rsync (ou cliente), você está no negócio. Se você for montá-lo na máquina de origem via SMB, então é melhor usar apenas 'cp' para copiar os arquivos.

    
por 24.09.2009 / 08:36
5

Parece que o registro de data e hora é um problema seu, já que esta página está relacionada:

link

A solução proposta é adicionar

--modify-window=1

para os parâmetros de rsync.

    
por 13.10.2009 / 23:33
4

Sim, você pode acelerar. Você precisa fazer com que a origem ou o destino pareçam com uma máquina remota, digamos, endereçando-a como " localhost: ".

Você afirmou que está montando o compartilhamento SMB localmente. Isso faz com que a origem ou o destino pareçam um caminho local para o rsync. A página do manual rsync indica que as cópias em que a origem e o destino são caminhos locais copiarão o arquivo inteiro. Isto é afirmado no parágrafo para a opção "--whole-file" na página man. Portanto, o algoritmo delta não é usado. Usar a solução alternativa " localhost: " restaurará a funcionalidade do algoritmo delta e acelerará as transferências.

    
por 16.08.2011 / 19:33
3

Pensei em jogar meu 2p aqui.

Meu irmão acabou de instalar um Buffalo NAS em sua rede de escritórios. Ele agora está olhando para backups fora do local, de modo que o escritório deve incendiar, pelo menos ele ainda tem todos os seus documentos de negócios em outros lugares (muitas centenas de quilômetros de distância).

Meu primeiro obstáculo foi conseguir o VPS que ele tem (um pequeno servidor privado virtual Linux, nada muito robusto) para discar como um usuário VPN para seu roteador de banda larga (ele está usando um DrayTek para isso) para que ele mesmo possa faça parte de sua VPN e, assim, pode acessar o NAS diretamente, de maneira segura. Tem que resolvido e trabalhando de forma brilhante.

O próximo problema foi então transferir os arquivos do NAS para o servidor VPS. Eu comecei fazendo uma montagem do Samba e encontrei exatamente o mesmo (ou pior) problema que você descreveu. Eu fiz um rsync a seco e demorou mais de 1 hora e 30 minutos apenas para descobrir quais arquivos ele iria transferir, porque, como diz Evan, sob esse método, o outro lado não é rsync, então ele tem que fazer muitos arquivamentos chamadas do sistema / leituras na montagem Samba (através de uma conexão PPTP / tunnelled, com um tempo de ida e volta de cerca de 40ms). Completamente impraticável.

Mal sabia eu que o Buffalo na verdade roda um daemon rsync então, usando isso, todo o dry-run leva apenas 1 minuto e 30 segundos para arquivos de 87k totalizando 50Gb. Obviamente, transferir 50Gb de arquivos (de um NAS que está em um link de banda larga com apenas 100k / s de largura de banda de saída) é outra questão (isso levará vários dias), mas, quando o rsync inicial for concluído, todos os backups incrementais devem ser clareamento de graxa (seus dados não vão mudar muito em uma base diária).

Minha sugestão é usar um NAS decente, que suporte rsync, pelas razões que Evan disse acima. Isso resolverá todos os seus problemas.

    
por 27.11.2010 / 17:09
0

Cheira como se você tivesse um NAS mais barato. Também pode ser da sua largura de banda de rede ...

O NAS "padrão" é muito fraco quando se trata de IO pesado, que é o que você está tentando fazer aqui. Também pode ser um switch barato conectando seu PC e seu NAS que não seja strong o suficiente para lidar com todos os pacotes corretamente.

    
por 24.09.2009 / 08:21
0

tente isso, pois aleast lhe dá 10% a mais que a velocidade de sua obtenção link

    
por 24.09.2009 / 08:25
0

Existem duas fontes potenciais do problema - ou você usa opções incorretas da linha de comentários ou seu NAS tem problemas com o registro de data e hora (ou ambos :-). Por favor, verifique este tópico "rsync para NAS copia tudo todas as vezes" para mais informações.

    
por 16.08.2011 / 20:20