Qual é a maneira mais rápida e confiável de transferir muitos arquivos?

Estou tentando transferir cerca de 100k arquivos, totalizando 90gb. No momento, estou usando o daemon rsync, mas seu lento 3.4mb / se preciso fazer isso várias vezes. Eu estou querendo saber quais opções eu tenho, que maximizariam uma conexão de 100mbit pela Internet e seriam muito confiáveis.

Você já considerou o Sneakernet ? Com grandes conjuntos de dados, o envio noturno geralmente será mais rápido e mais barato do que a transferência via Internet.

Quão? Ou TL; DR

O método mais rápido que encontrei é uma combinação de tar, mbuffere ssh.

Por exemplo:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Com isso, obtive transferências sustentadas de rede local acima de 950 Mb / s em links de 1Gb. Substitua os caminhos em cada comando tar para ser apropriado para o que você está transferindo.

Por quê? mbuffer!

O maior gargalo na transferência de arquivos grandes por uma rede é, de longe, a E / S do disco. A resposta para isso é mbufferou buffer. Eles são amplamente similares, mas mbuffertêm algumas vantagens. O tamanho padrão do buffer é 2 mbufferMB e 1 MB buffer. Buffers maiores têm maior probabilidade de nunca ficarem vazios. Escolher um tamanho de bloco que seja o menor múltiplo comum do tamanho de bloco nativo no sistema de arquivos de destino e de destino dará o melhor desempenho.

O buffer é a coisa que faz toda a diferença! Use-o se tiver! Se você não tiver, pegue! Usar (m}?buffermais qualquer coisa é melhor do que qualquer coisa por si só. é quase literalmente uma panacéia para transferências lentas de arquivos de rede.

Se você estiver transferindo vários arquivos, use-os tarpara "agrupá-los" em um único fluxo de dados. Se for um único arquivo, você poderá usar cato redirecionamento de E / S. A sobrecarga de tarvs. caté estatisticamente insignificante, então eu sempre uso tar(ou zfs -sendonde posso), a menos que já seja um tarball . Não é garantido que nenhum desses fornece metadados (e, em particular cat, não). Se você quiser metadados, deixarei isso como um exercício para você.

Finalmente, o uso sshde um mecanismo de transporte é seguro e carrega muito pouco em cima. Novamente, a sobrecarga de sshvs. ncé estatisticamente insignificante.

Você mencionou "rsync", então suponho que você esteja usando o Linux:

Por que você não cria um arquivo tar ou tar.gz? O tempo de transferência de rede de um arquivo grande é mais rápido do que muitos arquivos pequenos. Você pode até comprimir se desejar ...

Alcatrão sem compressão:

No servidor de origem:

tar -cf file.tar /path/to/files/

Então, no lado receptor:

cd /path/to/files/
tar -xf /path/to/file.tar

Alcatrão com compressão:

No servidor de origem:

tar -czf file.tar.gz /path/to/files/

Então, no lado receptor:

cd /path/to/files/
tar -xzf /path/to/file.tar.gz

Você simplesmente usaria o rsync para fazer a transferência real dos arquivos (tar | tar.gz).

Você poderia tentar o tare sshtruque descrito aqui :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"

isso deve ser regravável para o seguinte :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"

Você perderia os --partialrecursos do rsyncprocesso, no entanto. Se os arquivos não mudarem com muita frequência, viver com uma inicial lenta rsyncpode valer muito a pena, pois será muito mais rápido no futuro.

Você pode usar várias opções de compactação do rsync.

-z, --compress              compress file data during the transfer
     --compress-level=NUM    explicitly set compression level
     --skip-compress=LIST    skip compressing files with suffix in LIST

A taxa de compactação para arquivos binários é muito baixa, portanto você pode pular esses arquivos usando --skip-compress, por exemplo, iso, tarballs já arquivados e compactados etc.

Eu sou um grande fã do SFTP. Eu uso o SFTP para transferir mídia do meu computador principal para o meu servidor. Eu obtenho boas velocidades, através da LAN.

O SFTP é confiável, eu daria uma chance, pois é fácil de configurar e, em alguns casos, pode ser mais rápido.