tar + rsync + untar. Qualquer benefício de velocidade sobre apenas rsync?

Question

Muitas vezes me vejo enviando pastas com 10K - 100K de arquivos para uma máquina remota (dentro da mesma rede no campus).

Eu estava pensando se há razões para acreditar nisso,

 tar + rsync + untar

Ou simplesmente

 tar (from src to dest) + untar

poderia ser mais rápido na prática do que

rsync 

ao transferir os arquivos pela primeira vez .

Estou interessado em uma resposta que aborda o problema acima em dois cenários: usar compactação e não usá-la.

Atualizar

Acabei de executar algumas experiências movendo 10.000 arquivos pequenos (tamanho total = 50 MB) e tar+rsync+untar foi consistentemente mais rápido do que executar rsync diretamente (ambos sem compactação).

    

Answer 1

Quando você envia o mesmo conjunto de arquivos, rsync é mais adequado porque enviará apenas diferenças. tar sempre envia tudo e isso é um desperdício de recursos quando muitos dados já estão lá. O tar + rsync + untar perde essa vantagem nesse caso, bem como a vantagem de manter as pastas em sincronia com rsync --delete .

Se você copiar os arquivos pela primeira vez, primeiro empacotando, enviando e descompactando (AFAIK rsync não recebe entrada canalizada) é incômodo e sempre pior do que apenas rsyncing, porque rsync não terá para fazer qualquer tarefa mais que tar de qualquer maneira.

Dica: o rsync versão 3 ou posterior faz uma recursão incremental, o que significa que ele começa a copiar quase imediatamente antes de contar todos os arquivos.

Dica 2: se você usa rsync over ssh , você também pode usar tar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

ou apenas scp

scp -Cr srcdir user@server:destdir

Regra geral, mantenha-a simples.

ATUALIZAÇÃO:

Criei dados de demonstração de 59M

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

e testou várias vezes a transferência de arquivos para um servidor remoto (não no mesmo lan), usando ambos os métodos

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

enquanto mantém logs separados dos pacotes de tráfego ssh enviados

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

Nesse caso, não vejo nenhuma vantagem em menos tráfego de rede usando o rsync + tar, que é esperado quando o mtu padrão é 1500 e os arquivos têm tamanho de 10k. O rsync + tar gerava mais tráfego, ficava mais lento por 2-3 segundos e deixava dois arquivos inúteis que precisavam ser limpos.

Eu fiz os mesmos testes em duas máquinas na mesma lan, e o rsync + tar teve tempos muito melhores e muito menos tráfego de rede. Eu assumo a causa de quadros gigantes.

Talvez o rsync + tar seja melhor que apenas o rsync em um conjunto de dados muito maior. Mas francamente eu não acho que valha a pena, você precisa de espaço duplo em cada lado para empacotar e desfazer as malas, e há algumas outras opções, como já mencionei acima.

    

Answer 2

rsync também faz compactação. Use o sinalizador -z . Se estiver correndo sobre ssh , você também pode usar o modo de compressão do ssh. Minha sensação é que níveis repetidos de compressão não são úteis; apenas irá gravar ciclos sem resultados significativos. Eu recomendaria experimentar com a compactação rsync . Parece bastante eficaz. E eu sugeriria ignorar o uso de tar ou qualquer outra compressão pré / pós.

Eu costumo usar o rsync como rsync -abvz --partial... .

    

Answer 3

Eu tive que fazer o backup do meu diretório home para o NAS hoje e me deparei com essa discussão, pensei em adicionar meus resultados. Para encurtar a história, direcionar a rede para o sistema de arquivos de destino é muito mais rápido em meu ambiente do que rsyncing para o mesmo destino.

Ambiente: Área de trabalho da máquina fonte i7 usando disco rígido SSD. Máquina de destino Synology NAS DS413j em uma conexão de gigabit lan para a máquina de origem.

As especificações exatas do kit envolvido afetarão o desempenho, naturalmente, e eu não sei os detalhes da minha configuração exata com relação à qualidade do hardware de rede em cada extremidade.

Os arquivos de origem são minha pasta ~ / .cache, que contém 1,2Gb de arquivos muito pequenos.

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

Eu mantive 1a e 1b como etapas completamente separadas apenas para ilustrar a tarefa. Para aplicações práticas, eu recomendo o que Gilles postou acima envolvendo envios de tar com ssh para um processo de descompressão no receptor.

Horários:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

É muito claro que o rsync teve um desempenho incrivelmente fraco em comparação com uma operação de tar, que pode presumivelmente ser atribuída ao desempenho da rede mencionado acima.

Eu recomendaria qualquer pessoa que desejasse fazer backup de grandes quantidades de arquivos, em sua maioria pequenos, como um backup de diretório inicial, usando a abordagem tar. O rsync parece uma escolha muito ruim. Voltarei a este post se parecer que estou impreciso em qualquer um dos meus procedimentos.

Nick

    

Answer 4

Usar o rsync para enviar um arquivo tar como solicitado, na verdade, seria um desperdício ou recursos, pois você adicionaria uma camada de verificação ao processo. O Rsync faria checksum no arquivo tar para correção, quando você preferiria verificar os arquivos individuais. (Não ajuda saber que o arquivo tar que pode estar com defeito no lado de envio já mostra o mesmo efeito na extremidade de recebimento). Se você está enviando um arquivo, ssh / scp é tudo que você precisa.

O único motivo pelo qual você pode ter que selecionar o envio de um arquivo seria se o tar de sua escolha fosse capaz de preservar mais as especialidades do sistema de arquivos, como Lista de Controle de Acesso ou outros Metadados armazenados em Atributos Estendidos (Solaris) ou Recurso Garfos (MacOS). Ao lidar com essas coisas, sua principal preocupação será determinar quais ferramentas são capazes de preservar todas as informações associadas ao arquivo no sistema de arquivos de origem, desde que o sistema de arquivos de destino tenha a capacidade de controlá-las também.

Quando a velocidade é sua principal preocupação, depende muito do tamanho dos seus arquivos. Em geral, uma infinidade de minúsculos arquivos serão escalados de forma incorreta sobre rsync ou scp, já que todos irão desperdiçar pacotes de rede individuais, onde um arquivo tar incluiria vários deles dentro da carga de dados de um único pacote de rede. Melhor ainda se o arquivo tar fosse comprimido, já que os arquivos pequenos provavelmente seriam melhor compactados como um todo do que individualmente. Até onde sei, tanto o rsync quanto o scp não conseguem otimizar ao enviar arquivos inteiros como em uma transferência inicial, fazendo com que cada arquivo ocupe um quadro de dados inteiro com toda a sobrecarga de protocolo (e gastando mais com check-out). No entanto, Janecek afirma que isso é verdade apenas para scp, explicando que o rsync otimizaria o tráfego da rede, mas ao custo de construir estruturas de dados enormes na memória. Veja o artigo Transferência eficiente de arquivos, Janecek 2006 . Então, de acordo com ele, ainda é verdade que scp e rsync escalam mal em arquivos pequenos, mas por razões completamente diferentes. Acho que vou ter que pesquisar fontes neste fim de semana para descobrir.

Para relevância prática, se você sabe que está enviando arquivos maiores, não haverá muita diferença na velocidade, e usar o rsync tem o benefício adicional de ser capaz de continuar onde foi interrompido.

Postscriptum: Nos dias de hoje, o rdist parece cair no esquecimento, mas antes dos dias de rsync, era uma ferramenta muito capaz e amplamente usada (com segurança quando usado em ssh, inseguro de outra forma). Eu não teria um desempenho tão bom quanto o rsync, já que ele não otimizava apenas a transferência de conteúdo que havia sido alterado. Sua principal diferença para o rsync reside na maneira como ele é configurado e como as regras para atualização de arquivos são explicitadas.

    

Answer 5

Para diretórios pequenos (pequenos como no espaço em disco usado), isso depende da sobrecarga de verificar as informações do arquivo para os arquivos que estão sendo sincronizados. Por um lado, rsync economiza o tempo de transferência dos arquivos não modificados; por outro lado, ele precisa transferir informações sobre cada arquivo.

Eu não sei exatamente os internos de rsync . Se as estatísticas do arquivo causam defasagem depende de como rsync transfere dados - se as estatísticas do arquivo forem transferidas uma por uma, o RTT pode tornar o tar + rsync + untar mais rápido.

Mas se você tiver, digamos, 1 GiB de dados, o rsync será bem mais rápido, bem, a menos que sua conexão seja realmente rápida!

    

Answer 6

Horário:

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"