Costumo me enviar pastas com 10.000 a 100.000 arquivos para uma máquina remota (dentro da mesma rede no campus).

Eu só estava me perguntando se existem 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 acima em dois cenários: usando compressão e não usá-lo.

Atualizar

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

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

Se você copiar os arquivos pela primeira vez, primeiro empacotando, enviando e enviando, a descompactação (o AFAIK rsyncnão aceita entrada canalizada) é complicada e sempre pior do que apenas sincronizar, porque rsyncnão precisará executar mais nenhuma tarefa tar.

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

Dica 2: se você usar rsyncmais ssh, também poderá usartar+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-o simples.

ATUALIZAR:

Criei dados de demonstração de 59 milhões

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 na mesma LAN), usando os dois 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

mantendo registros 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, o que é esperado quando o mtu padrão é 1500 e enquanto os arquivos têm tamanho de 10k. O rsync + tar gerou mais tráfego, ficou mais lento por 2-3 segundos e deixou dois arquivos de lixo que precisavam ser limpos.

Fiz os mesmos testes em duas máquinas na mesma LAN e o rsync + tar fez tempos muito melhores e muito menos tráfego de rede. Eu assumo a causa dos quadros jumbo.

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

rsynctambém faz compressão. Use a -zbandeira. Se atropelar ssh, você também pode usar o modo de compactação do ssh. Meu sentimento é que níveis repetidos de compressão não são úteis; apenas queimará ciclos sem resultado significativo. Eu recomendo experimentar a rsynccompactação. Parece bastante eficaz. E eu sugiro ignorar o uso tarou qualquer outra compressão pré / pós.

Eu normalmente uso o rsync como rsync -abvz --partial....

Eu tive que fazer backup do meu diretório pessoal no NAS hoje e entrei nessa discussão, pensando em adicionar meus resultados. Para encurtar a história, percorrer a rede até o sistema de arquivos de destino é muito mais rápido no meu ambiente do que sincronizar no mesmo destino.

Ambiente: Desktop da máquina i7 de origem usando o disco rígido SSD. Máquina de destino Synology NAS DS413j em uma conexão LAN de gigabit com a máquina de origem.

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

Os arquivos de origem são minha pasta ~ / .cache, que contém 1,2 GB 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 recomendaria o que Gilles postou acima, envolvendo a saída de alcatrão de tubulação via ssh para um processo ininterrupto no receptor.

Horários:

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

Está muito claro que o rsync teve um desempenho surpreendentemente ruim em comparação com uma operação tar, que pode ser atribuída ao desempenho de rede mencionado acima.

Eu recomendo quem quiser fazer backup de grandes quantidades de arquivos principalmente pequenos, como um backup do diretório inicial, use a abordagem tar. O rsync parece uma escolha muito ruim. Voltarei a este post se parece que não tenho precisão em nenhum dos meus procedimentos.

usuario

Usar o rsync para enviar um arquivo tar, conforme solicitado, na verdade seria um desperdício ou recursos, pois você adicionaria uma camada de verificação ao processo. O Rsync soma o checksum ao arquivo tar, se você preferir 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 no lado de recebimento). Se você estiver enviando um arquivo, ssh / scp é tudo que você precisa.

O único motivo pelo qual você deve selecionar o envio de um arquivo morto seria se o alcatrão de sua escolha pudesse preservar mais itens especiais do sistema de arquivos, como Lista de Controle de Acesso ou outros Metadados frequentemente armazenados em Atributos Estendidos (Solaris) ou Ressource Forks (MacOS) ) Ao lidar com essas coisas, sua principal preocupação será com relação a 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 acompanhá-las também.

Quando a velocidade é sua principal preocupação, depende muito do tamanho dos seus arquivos. Em geral, uma infinidade de arquivos minúsculos sofrerá uma escala ruim em relação ao rsync ou scp, pois todos eles desperdiçarão pacotes de rede individuais, onde um arquivo tar incluiria vários deles na carga de dados de um único pacote de rede. Melhor ainda se o arquivo tar fosse compactado, pois os arquivos pequenos provavelmente seriam compactados melhor como um todo do que individualmente. Até onde eu sei, o rsync e o scp falham ao otimizar ao enviar arquivos únicos inteiros como em uma transferência inicial, tendo cada arquivo ocupado um quadro de dados inteiro com todo o seu protocolo sobrecarga (e desperdiçando mais em verificar e voltar). No entanto Janecekafirma que isso é verdade apenas para scp, detalhando que o rsync otimizaria o tráfego da rede, mas ao custo de criar enormes estruturas de dados na memória. Consulte o artigo Transferência eficiente de arquivos, Janecek 2006 . Portanto, de acordo com ele, ainda é verdade que o scp e o rsync escalam mal em arquivos pequenos, mas por razões totalmente diferentes. Acho que vou ter que procurar fontes neste fim de semana para descobrir.

Por relevância prática, se você sabe que está enviando arquivos majoritariamente maiores, não haverá muita diferença de velocidade, e o uso do rsync tem o benefício adicional de poder continuar onde parou quando interrompido.

Postscriptum: Hoje em dia, o rdist parece afundar no esquecimento, mas antes dos dias do rsync, era uma ferramenta muito capaz e amplamente utilizada (com segurança quando usada sobre ssh, caso contrário não era segura). Eu não teria um desempenho tão bom quanto o rsync, pois ele não otimizava apenas a transferência de conteúdo que havia sido alterado. Sua principal diferença para o rsync está na maneira como ele é configurado e como as regras para atualização de arquivos são definidas.

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, rsynceconomiza o tempo de transferência dos arquivos não modificados; por outro lado, ele realmente precisa transferir informações sobre cada arquivo.

Eu não sei exatamente o interior de rsync. Se as estatísticas do arquivo causam atraso depende de como rsynctransfere os dados - se as estatísticas do arquivo são transferidas uma a uma, o RTT pode tornar o tar + rsync + untar mais rápido.

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

Eu tive que mover alguns terabytes de dados pelo país, exatamente uma vez. Como experimento, executei duas transferências usando rsynce ssh/tarpara ver como elas se comparam.

Os resultados:

• rsync transferiu os arquivos a uma taxa média de 2,76 megabytes por segundo.
• ssh/tar transferiu os arquivos a uma taxa média de 4,18 megabytes por segundo.

Os detalhes: Meus dados consistem em milhões de arquivos compactados em .gz, cujo tamanho médio é de 10 megabytes, mas alguns têm mais de um gigabyte. Existe uma estrutura de diretórios, mas é diminuída pelo tamanho dos dados dentro dos arquivos. Se eu tivesse quase mais alguma coisa para fazer, eu teria usado apenas, rsyncmas neste caso, a ssh/tarsolução é funcional.

Meu trabalho rsyncconsiste em:

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

onde fileList.txt é uma grande lista longa dos nomes de caminho relativos dos arquivos do outro lado. (Observei que --compressnão é produtivo para arquivos compactados depois que iniciei, mas não voltaria a reiniciar.)

Comecei outro com ssh e tar que tem:

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

Você observará isso copia tudo, desculpe, isso não é uma comparação de maçãs com maçãs de 100%.

Devo acrescentar que, enquanto uso a rede interna da empresa, preciso passar por um intermediário para acessar o computador da fonte de dados. O tempo de ping do meu computador de destino para o intermediário é de 21 ms e do intermediário para a fonte de dados é de 26 ms. Foi o mesmo para as duas transferências.

A conexão SSL através do intermediário é realizada através da ~/.ssh/configentrada:

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

Tempo isto:

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