Como copiar um grande número de arquivos rapidamente entre dois servidores

Question

Eu preciso transferir uma quantidade enorme de mp3s entre dois servidores (Ubuntu). Por enorme eu quero dizer cerca de um milhão de arquivos que são, em média, 300K. Eu tentei com scp , mas levaria cerca de uma semana. (cerca de 500 KB / s) Se eu transferir um único arquivo por HTTP, recebo 9-10 MB / s, mas não sei como transferir todos eles.

Existe uma maneira de transferir todos eles rapidamente?

    

Answer 1

Eu recomendaria tar. Quando as árvores de arquivos já são semelhantes, o rsync executa bem muito . No entanto, como o rsync faz várias análises de análise em cada arquivo e copia as alterações, é muito mais lento que o tar para a cópia inicial. Este comando provavelmente fará o que você quiser. Ele copia os arquivos entre as máquinas, além de preservar as permissões e as permissões de usuário / grupo.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Conforme o comentário de Mackintosh abaixo, este é o comando que você usaria para o rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

    

Answer 2

Disco rígido externo e entrega de correio no mesmo dia.

    

Answer 3

Eu usaria o rsync.

Se você os exportou via HTTP com listagens de diretórios disponíveis, você pode usar wget e o argumento --mirror também.

Você já está vendo que o HTTP é mais rápido que o SCP porque o SCP está criptografando tudo (e, portanto, o gargalo na CPU). O HTTP e o rsync vão se mover mais rápido porque não estão criptografando.

Aqui estão alguns documentos sobre como configurar o rsync no Ubuntu: link

Esses documentos falam sobre o tunelamento de rsync por SSH, mas se você está apenas movendo dados em uma LAN privada, não precisa de SSH. (Eu estou supondo que você está em uma LAN privada. Se você está recebendo 9-10MB / sec através da Internet, então eu quero saber que tipo de conexões você tem!)

Aqui estão alguns outros documentos muito básicos que permitirão que você configure um servidor rsync relativamente inseguro (sem dependência do SSH): link

    

Answer 4

Sem muita discussão, use o netcat, network swissarmy knife. Nenhuma sobrecarga de protocolo, você está copiando diretamente para o soquete da rede. Exemplo

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

    

Answer 5

Com muitos arquivos, se você for usar o rsync, tentarei obter a versão 3 ou superior nas duas extremidades . A razão é que uma versão menor irá enumerar todos os arquivos antes de iniciar a transferência. O novo recurso é chamado de recursão incremental .

A new incremental-recursion algorithm is now used when rsync is talking to another 3.x version. This starts the transfer going more quickly (before all the files have been found), and requires much less memory. See the --recursive option in the manpage for some restrictions.

    

Answer 6

rsync, como outros já recomendaram. Se a sobrecarga da CPU da criptografia for um gargalo, use outro algoritmo menos intensivo da CPU, como o blowfish. Por exemplo. algo como

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

    

Answer 7

Ao copiar um grande número de arquivos, descobri que ferramentas como tar e rsync são mais ineficientes do que precisam devido à sobrecarga de abrir e fechar muitos arquivos. Eu escrevi uma ferramenta de código aberto chamada fast-archiver que é mais rápida que o tar para esses cenários: link ; funciona mais rápido executando várias operações simultâneas de arquivos.

Aqui está um exemplo de arquivamento rápido versus tar em um backup de mais de dois milhões de arquivos; o arquivador rápido leva 27 minutos para ser arquivado, enquanto o tar leva 1 hora e 23 minutos.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading '/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Para transferir arquivos entre servidores, você pode usar o arquivador rápido com o ssh, assim:

ssh [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

    

Answer 8

Ao mover 80 TB de dados (milhões de arquivos minúsculos) ontem, mudar de rsync para tar provou ser muito mais rápido , quando paramos de tentar

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

e alternou para tar em vez disso ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Como esses servidores estão na mesma LAN, o destino é montado por NFS no sistema de origem, que está fazendo o push. Não seja ainda mais rápido, decidimos não preservar o atime dos arquivos:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

O gráfico abaixo mostra a diferença da alteração de rsync para tar feita. Foi a minha ideia do chefe e o meu colega executou-a e fez o grande writeup em seu blog . Eu apenas gosto de fotos bonitas . :)

    

Answer 9

Eu também uso o tar através da abordagem netcat , exceto que eu prefiro usar socat - muito mais poder para otimizar sua situação - por exemplo, modificando o mss. (Além disso, ria se quiser, mas acho que socat argumentos é mais fácil de lembrar porque eles são consistentes). Então, para mim, isso é muito comum ultimamente, já que estou movendo coisas para novos servidores:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Os aliases são opcionais.

    

Answer 10

Outra alternativa é Unison . Pode ser um pouco mais eficiente que o Rsync, e é mais fácil configurar um ouvinte.

    

Answer 11

Parece que pode haver alguns erros de digitação na resposta principal. Isso pode funcionar melhor:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

    

Answer 12

• Network File System (NFS) e copie-os com o que quiser, por ex. Midnight Commander (mc), Nautilus (do gnome). Eu usei o NFS v3 com bons resultados.
• Samba (CIFS) e copie os arquivos com o que você quiser, mas não tenho idéia de como é eficiente.
• HTTP com wget --mirror como Evan Anderson sugeriu ou qualquer outro cliente http. Tenha cuidado para não ter quaisquer links simbólicos desagradáveis ou arquivos de índice enganosos. Se tudo o que você tem são MP3s, você deve estar seguro.
• rsync . Eu usei-o com resultados muito bons e uma das suas características legais é que você pode interromper e retomar a transferência mais tarde.

Eu notei que outras pessoas recomendaram o uso de netcat . Com base em minha experiência , posso dizer que é lento em comparação com outras soluções.

    

Answer 13

Eu não acho que você vai fazer nada melhor do que scp, a menos que você instale placas de rede mais rápidas. Se você está fazendo isso pela internet, isso não ajudará.

Eu recomendaria usar o rsync . Pode não ser mais rápido, mas pelo menos se falhar (ou se você desligar porque está demorando demais), você pode continuar de onde parou da próxima vez.

Se você puder conectar as duas máquinas diretamente usando o gigabit ethernet, provavelmente será o mais rápido.

    

Answer 14

Para 100Mb / s, o throughput teórico é de 12,5 MB / s, então, com 10MB / s, você está indo muito bem.

Gostaria também de fazer eco à sugestão de fazer o rsync, provavelmente através do ssh. Algo como:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

A 100Mb / s, suas CPUs devem ser capazes de processar a criptografia / decodificação sem afetar significativamente a taxa de dados. E se você interromper o fluxo de dados, poderá retomar a partir de onde parou. Cuidado, com "milhões" de arquivos a inicialização vai demorar um pouco antes de realmente transferir alguma coisa.

    

Answer 15

Um scp simples com as opções adequadas alcançará facilmente 9-10 MB / s em LAN:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

Com essas opções, é provável que a taxa de transferência tenha se tornado 4x ou 5x mais rápida do que nenhuma opção (padrão)

    

Answer 16

Você também pode tentar usar o comando BBCP para fazer sua transferência. É um ssh paralelo em buffer que realmente grita. Geralmente, podemos obter 90% de taxa de linha, desde que possamos manter o tubo alimentado.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Normalmente, nos esforçamos muito para não ter que nos mover. Usamos pools do ZFS nos quais podemos sempre "adicionar" mais espaço em disco para. Mas às vezes ... você só tem que mover coisas. Se nós tivermos um sistema de arquivos "ao vivo" que pode levar horas (ou dias) para copiar, mesmo quando você estiver executando o full-blast ... nós fazemos o ole two step zfs send routine:

1. Faça um instantâneo do ZFS e transfira para o novo pool no novo computador. Deixe levar o tempo que for preciso.
2. Faça um segundo instantâneo e envie-o como um incremental. O instantâneo incremental inclui apenas o conjunto de mudanças (muito menor) desde o primeiro, portanto, ele passa relativamente rápido.
3. Quando o instantâneo incremental estiver concluído, você poderá transformar o original e recortar para a nova cópia, e seu "tempo de inatividade off-line" será reduzido ao mínimo.

Também enviamos nossos dumps zfs ao BBCP, maximizando a utilização da rede e minimizando os tempos de transferência.

O BBCP está disponível gratuitamente, você pode pesquisar no Google e é uma compilação direta. Basta copiá-lo para o seu / usr / local / bin em ambas as máquinas src e destination e ele praticamente funcionará.

    

Answer 17

rsync ou você pode querer tar assim tudo dentro de um arquivo e, em seguida, scp. Se você não tiver o espaço em disco, poderá canalizar o tar diretamente sobre o ssh enquanto ele estiver sendo feito.

    

Answer 18

Se você estiver enviando arquivos MP3 e outros arquivos compactados, não ganhará muito com qualquer solução que tente compactar ainda mais esses arquivos. A solução seria algo que pode criar várias conexões entre os dois servidores e, assim, colocar mais pressão na largura de banda entre os dois sistemas. Quando isso se esgotar, não há muito que possa ser ganho sem melhorar seu hardware. (Cartões de rede mais rápidos entre esses servidores, por exemplo).

    

Answer 19

Encontrei isso, exceto que estava transferindo logs do Oracle.

Aqui está o detalhamento

• scp

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

Eu usei FTP com grande sucesso (onde grande sucesso é equivalente a ~ 700Mb / s em uma rede Gb). Se você está recebendo 10MB (o que equivale a 80Mb / s), provavelmente há algo errado.

O que você pode nos dizer sobre a origem e o destino dos dados? É single drive para drive único? RAID para USB?

Eu sei que esta pergunta já tem uma resposta, mas se sua rede está indo tão devagar em um cabo cruzado Gb / s, algo absolutamente precisa ser corrigido.

    

Answer 20

Você não mencionou se as duas máquinas estão na mesma LAN, ou se um canal seguro (ou seja, usando SSH) é obrigatório, mas outra ferramenta que você pode usar é netcat .

Eu usaria o seguinte na máquina de recebimento:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Em seguida, no lado do envio:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Tem as seguintes vantagens:

• Nenhuma sobrecarga de CPU para a criptografia que o ssh tem.
• O gzip -1 fornece compactação leve sem saturar uma CPU, por isso faz um bom compromisso, proporcionando um pouco de compactação, mantendo o throughput máximo. (Provavelmente não é vantajoso para os dados de MP3, mas não faz mal.)
• Se você puder particionar os arquivos em grupos, poderá executar dois ou mais canais em paralelo e realmente garantir que esteja saturando sua largura de banda de rede.

por exemplo,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Notas:

• Qualquer que seja a forma de transferência, provavelmente executaria um rsync ou uníssono para garantir que você tenha tudo .
• Você poderia usar tar em vez de cpio se preferir.
• Mesmo que você acabe usando o ssh, eu asseguro que ele não esteja usando nenhuma compactação e canalize gzip -1 para evitar a saturação da CPU. (Ou, pelo menos, defina o CompressionLevel como 1).

Answer 21

Eu tentei algumas ferramentas para copiar um arquivo de 1GB O resultado está abaixo: HTTP o mais rápido, com wget -c nc segundo na fila scp mais lento e falhou algumas vezes. Não há maneira de retomar O rsync usa o ssh como backend, portanto, o mesmo resultado. Em conclusão, eu iria para http com wget -bqc e dar-lhe algum tempo. Espero que isso ajude

    

Answer 22

Eu tive que copiar o disco do BackupPC em outra máquina.

Eu usei o rsync.

A máquina tinha 256 MB de memória.

O procedimento que eu segui foi este:

• executado rsync sem -H (demorou 9 horas)
• quando o rsync terminou, sincronizei o diretório cpool e iniciei com o diretório pc ; Eu cortei a transferência.
• em seguida, reiniciado rsync com -H flag e todos os arquivos vinculados com disco no diretório pc foram corretamente transferidos (o procedimento encontrou todos os arquivos reais em cpool e, em seguida, vinculados ao diretório pc ) (demorou 3 horas).

No final, pude verificar com df -m que nenhum espaço extra foi gasto.

Desta forma eu iludo o problema com a memória e o rsync. Toda vez que posso verificar o desempenho usando o topo e no topo e finalmente eu transferi 165 GB de dados.

    

Answer 23

Se você tiver o servidor ftp no lado src, poderá usar o ncftpget do site ncftp . Ele funciona prefeito com arquivos pequenos, pois usa o tar internamente.

Uma comparação mostra isso: movendo arquivos pequenos de 1,9 GB (33926 arquivos)

1. Usando scp leva 11m59s
2. Usando o rsync leva 7m10s
3. Usando o ncftpget leva 1m20s

Answer 24

Acho que minha resposta está um pouco atrasada aqui, mas fiz boas experiências com o uso do mc (Midnight Commander) em um servidor para conectar via SFTP ao outro servidor.

A opção de conexão via FTP está nos menus "Esquerda" e "Direita", inserindo o endereço como este:

/#ftp:[email protected]/

ou

/#ftp:[email protected]/

Você pode navegar e fazer operações de arquivos quase como em um sistema de arquivos local.

Tem uma opção embutida para fazer a cópia em segundo plano, mas eu prefiro usar o comando screen e desanexar da tela enquanto o mc está copiando (acho que ele roda mais rápido do que o tempo todo).

    

Answer 25

Para responder @scottpack da opção rSync

Para exibir o progresso do upload, use '--progess' como opção após -avW no comando, conforme mostrado abaixo.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir