Como posso copiar um grande número de pequenos arquivos no scp?

Question

Eu tenho um diretório que tem vários gigabytes e vários milhares de arquivos pequenos. Eu quero copiá-lo através da rede com scp mais de uma vez. O tempo de CPU nas máquinas de origem e de destino é barato, mas a sobrecarga de rede adicionada ao copiar cada arquivo individualmente é enorme. Eu iria tar / gzip-lo e enviá-lo, mas a máquina de origem é curto no disco.

Existe uma maneira de canalizar a saída de tar -czf <output> <directory> para scp? Se não, existe outra solução fácil? Minha máquina de origem é antiga (SunOS), então prefiro não instalar coisas nela.

    

Answer 1

Você pode canalizar o tar em uma sessão ssh:

$ tar czf - <files> | ssh user@host "cd /wherever && tar xvzf -"

    

Answer 2

Alcatrão com compressão bzip2 deve tirar o máximo de carga da rede e da cpu.

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

Não usando -v porque a saída da tela pode atrasar o processo. Mas se você quiser uma saída detalhada, use-a no lado local do tar ( -jcvf ), não na parte remota.

Se você copiar repetidamente o mesmo caminho de destino, como atualizar uma cópia de backup, sua melhor opção será rsync com compactação.

$ rsync -az -e ssh /path/to/src/dir/ user@server:/path/to/dest/dir/

Observe que os caminhos src e dest terminam com um /. Novamente, não usando -v e -P sinalizadores de propósito, adicione-os se precisar de uma saída detalhada.

    

Answer 3

use rsync , ele usa SSH.

Uso:

rsync -aPz /source/path destination.server:remote/path

Os switches rsync se preocupam com a compactação e as informações do nó I. -P exibe o progresso de cada arquivo.

Você pode usar scp -C , que permite a compactação, mas, se possível, use rsync .

    

Answer 4

Você pode executar tar em ambas as extremidades usando ssh. scp é parte da família ssh do bem, então você provavelmente tem isso em ambas as extremidades.

 8:03AM 12 % tar cf - some_directory | ssh dest_host "tar xf -"

Pode haver uma maneira de trabalhar o gzip ou o bzip2 no pipeline para diminuir o tráfego da rede também.

    

Answer 5

Se você tiver gzip nas duas extremidades: sourcehost$ cd sourcedir && tar cf - . | gzip -c - | ssh user@destinationhost "cd destinationdir && gzip -c -d | tar xf -"

Se você não tiver gzip na máquina de origem, verifique se descompactou no destino: sourcehost$ cd sourcedir && tar cf - . | compress | ssh user@destinationhost "cd destdir && uncompress | tar xf -"

Isso seria mais rápido do que o primeiro compactar, depois enviar, descompactar e não requer espaço extra em disco nos dois lados. Eu digitei o sinalizador de compactação (z) no tar, porque você provavelmente não o tem no lado antigo.

    

Answer 6

Ou você pode fazer o contrário se precisar. Isso é puxar o tarball pela rede em vez de empurrá-lo como foi sugerido. Isso não resolve a parte repetida de sua pergunta e o rsync é melhor para isso, mas provavelmente há opções de tar para ajudar.

Então, na máquina local:

ssh remote 'tar zcf - /etc/resolv.conf' | tar zxf -

Melhor estar no diretório correto primeiro ou você tem que usar o switch -C no comando untaring no final.

Apenas mencionando isso, caso isso seja necessário. É para mim como na minha situação o meu servidor local está por trás do nat, então eu levaria algumas redes para poder fazê-lo da maneira que foi mencionada anteriormente.

HTH

    

Answer 7

@ pdo's answer is good, mas pode-se aumentar a velocidade com um buffer e boa compressão e adicionar uma barra de progresso.

Geralmente, a rede é o gargalo e a velocidade varia com o tempo. Portanto, ajuda a armazenar os dados antes de enviá-los pela rede. Isso pode ser feito com pv .

Além disso, geralmente é possível aumentar a velocidade com um algoritmo de compactação adequado. O Gzip (como usado acima) é um algoritmo de compressão rápida, mas em geral zstandard ( zstd ) (e para altas taxas de compactação LZMA / LZMA2 ( xz ) irá compactar melhor e ser mais rápido ao mesmo tempo Novo xz e zstd suporte multicore já embutido. Para usar gzip com múltiplos núcleos pigz pode ser usado.

Aqui está um exemplo para enviar dados com uma barra de progresso, buffering e compactação zstandard em uma rede:

tar cf - . | pv -perabs $(du -sk . | cut -f 1)K | zstd -14 --long=31 -T0 | pv -qCB 512M | ssh user@host "cd /wherever && pv -qCB 512M | zstd -cd -T0 --long=31 | tar xf -"

O primeiro pv é mostrar o progresso ( p ), tempo estimado ( e ), taxa de transferência ( r ), taxa média ( a ), total de bytes transferidos ( b ). O tamanho total é estimado com du e adicionado à opção de tamanho ( s ). O progresso é medido antes da compressão e do buffer, portanto, não é muito preciso, mas ainda é útil.

zstd é usado com a configuração de compactação 14 . Esse número pode ser reduzido ou aumentado dependendo da rede e da velocidade da CPU, então zstd é um pouco mais rápido que a velocidade da rede. Com quatro núcleos em um processador Haswell de 3,2 GHz, o 14 oferece uma velocidade de cerca de 120 MB / s. No exemplo, o modo longo 31 (usa uma janela de 2 GB, precisa de muita RAM, mas muito bom, por exemplo, para compactar dumps de banco de dados) é usado. As opções T0 definem a quantidade de encadeamentos para o número de núcleos. Deve-se estar ciente de que, juntamente com o modo longo, essas configurações usam muita memória.

Um problema com o zstd é que a maioria dos sistemas operacionais não é fornecida com a versão > = 1.3.4. Esta versão é necessária para suporte multi core e longo. Se não estiver disponível, pode ser compilado e instalado a partir do link com apenas make -j4 && sudo make install . Em vez de zstd, também é possível usar xz ou pigz. xz é lento, mas comprime muito bem (conexões boas em cima de lentas), o pigz / gzip é rápido mas não comprime tão bem. pv é então usado novamente, mas para buffer ( q para quiet, C para o modo no splice [sempre necessário para buffer] e B para definir o tamanho do buffer).

No exemplo, um buffer também é usado no lado do receptor. Isso geralmente é desnecessário (porque a velocidade de gravação do disco rígido e da descompactação é maior que a velocidade da rede), mas geralmente não causa danos.

    

Answer 8

Ou monte o sistema de arquivos remoto via sshfs

sshfs user@remotehost:/path/on/remote /path/on/local

    

Answer 9

Embora não seja o mais elegante, especialmente porque não está copiando um único arquivo zip ou tar e duplamente de forma que não ajude a reduzir o ovehead de rede, minha única escolha foi usar scp -r :

-r

Recursively copy entire directories.  Note that scp follows symbolic links encountered in the tree traversal.

^{Source: scp(1)}

Eu estava com problemas em ficar sem espaço em disco com um arquivo tar compactado de 30 GB. Eu pensei que o gunzip poderia fazer isso in-line, ou seja, remover o original enquanto ele estava sendo descompactado (e eu posso ter perdido um resultado do Google), mas não consegui encontrar nada.

Finalmente, porque estava cansado de tentar várias vezes esperar que um novo arquivo TAR ou ZIP terminasse de tarar ou zipar, finalmente acabei de fazer:

1. Do servidor / PC / laptop original, navegue até o diretório em que sua pasta possui vários arquivos / pastas.
2. scp -r source_folder_name yourname@yourservername:destination_folder_name

Em seguida, basta pegar um pouco de cerveja, café ou pipoca e esperar. O bom é que o scp tentará novamente se a conexão de rede "parar". Só espero que não desapareça completamente.