ti-enxame.com

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

Preciso transferir uma quantidade enorme de mp3s entre dois serviços (Ubuntu). Por enorme, 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 de 9 a 10 MB/s, mas não sei como transferi-los.

Existe uma maneira de transferir todos eles rapidamente?

96
nicudotro

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

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

De acordo com 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
119
Scott Pack

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

38
Adam

Eu usaria rsync.

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

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

Aqui estão alguns documentos sobre como configurar o rsync no Ubuntu: https://help.ubuntu.com/community/rsync

Esses documentos falam sobre o tunelamento do rsync pelo SSH, mas se você está apenas movendo dados em uma LAN privada, não precisa do SSH. (Suponho que você esteja em uma LAN privada. Se você está recebendo 9 a 10 MB/s pela Internet, quero saber que tipo de conexões você possui!)

Aqui estão outros documentos muito básicos que permitem configurar um servidor rsync relativamente inseguro (sem dependência do SSH): http://transamrit.net/docs/rsync/

17
Evan Anderson

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

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

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

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

Um novo algoritmo de recursão incremental agora é usado quando o rsync está conversando com outra versão 3.x. Isso inicia a transferência mais rapidamente (antes que todos os arquivos sejam encontrados) e requer muito menos memória. Veja a opção --recursive na página de manual para algumas restrições.

8
Kyle Brandt

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

rsync -ax -e 'ssh -c blowfish' /local/path [email protected]:/remote/path

7
janneb

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

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

e mudou 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 em NFS no sistema de origem, que está executando o Push. Não deixe ainda mais rápido, decidimos não preservar os atime dos arquivos:

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

O gráfico abaixo mostra a diferença entre a mudança de rsync e alcatrão. Foi minha ideia do chefe e minha colega a executou e fez a ótima redação em seu blog . Eu apenas gosto fotos bonitas . :)

rsync_vs_tar

7
Philip Durbin

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 arquivador rápido que é mais rápida que o tar para esses cenários: https://github.com/replicon/fast-archiver ; ele funciona mais rápido executando várias operações de arquivo simultâneas.

Aqui está um exemplo de arquivador rápido x tar em um backup de mais de dois milhões de arquivos; o arquivador rápido leva 27 minutos para arquivar, contra o tar levando 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 ssh, assim:

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

Também uso o tar através da abordagem netcat, exceto que prefiro usar socat - muito mais poder para otimizar sua situação - por exemplo, ajustando o mss. (Além disso, ria se quiser, mas acho mais fácil lembrar os argumentos socat porque são consistentes). Então, para mim, isso é muito comum ultimamente, pois tenho mudado as coisas para novos servidores:

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

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

Aliases são opcionais.

3
R. Francis Smith
  • Sistema de arquivos de rede (NFS) e copie-os com o que quiser, por exemplo Comandante da meia-noite (mc), Nautilus (do gnomo). 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 quão eficiente é.
  • [~ # ~] http [~ # ~] com wget --mirror as Evan Anderson sugeriu ou qualquer outro cliente http. Cuidado para não ter links simbólicos desagradáveis ​​ou arquivos de índice enganosos. Se tudo o que você tem é MP3, você deve estar seguro.
  • rsync . Usei-o com bons resultados e um dos seus recursos agradáveis ​​é que você pode interromper e retomar a transferência posteriormente.

Notei que outras pessoas recomendaram o uso de netcat. Baseado em minha experiência com ele, posso dizer que é lento em comparação com as outras soluções.

2
Cristian Ciupitu

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

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

Graças à maravilhosa resposta de Scott Pack (eu não sabia como fazer isso com o ssh antes), posso oferecer essa melhoria (se bash for o seu Shell). Isso adicionará compactação paralela, um indicador de progresso e verificará a integridade no link de rede:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv é um bom programa de visualização de progresso para o seu pipe e pigz é um programa gzip paralelo que usa quantos threads a sua CPU possui por padrão (acredito que até 8 no máximo). Você pode ajustar o nível de compactação para ajustar melhor a proporção da CPU à largura de banda da rede e trocá-lo com pxz -9e e pxz -d se você tiver muito mais CPU que largura de banda. Você só precisa verificar se as duas somas correspondem após a conclusão.

Essa opção é útil para quantidades muito grandes de dados, bem como para redes de alta latência, mas não é muito útil se o link estiver instável e cair. Nesses casos, o rsync é provavelmente a melhor opção possível.

Saída de amostra:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Para dispositivos de bloco:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Obviamente, verifique se eles têm o mesmo tamanho ou limite com count =, skip =, seek =, etc.

Quando copio sistemas de arquivos dessa maneira, geralmente vou primeiro dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs para zerar a maior parte do espaço não utilizado, o que acelera o xfer.

2
Daniel Santos

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

2
Adam D'Amico

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ê poderia usar é netcat .

Eu usaria o seguinte na máquina receptora:

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

Depois, no lado de 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 possui.
  • O gzip -1 fornece compactação leve sem saturar a CPU, fazendo uma boa troca, oferecendo um pouco de compactação, mantendo o rendimento máximo. (Provavelmente não é tão vantajoso para dados MP3, mas não dói.)
  • Se você puder particionar os arquivos em grupos, poderá executar dois ou mais pipes em paralelo e realmente garantir que está saturando a largura de banda da 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 como você transfira, eu provavelmente executaria um rsync ou níssono depois para garantir que você tenha tudo.
  • Você pode usar tar em vez de cpio se preferir.
  • Mesmo que você acabe usando o ssh, eu garantiria que ele não esteja usando nenhuma compressão em si e canalize através de gzip -1 você mesmo para evitar a saturação da CPU. (Ou pelo menos defina o CompressionLevel como 1.)
1
Evan

Se você tiver um servidor ftp no lado src, poderá usar ncftpget em site ncftp . Ele funciona perfeitamente com arquivos pequenos, pois utiliza tar internamente.

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

  1. Usando scp leva 11m59s
  2. O uso do rsync leva 7m10s
  3. Usar ncftpget leva 1m20s
1
Ali Nikneshan

Você também pode tentar usar o comando BBCP para fazer sua transferência. É um ssh paralelo em buffer que realmente grita. Normalmente, podemos obter 90% + 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, nós nos esforçamos muito para evitar ter que nos mexer. Usamos pools do ZFS aos quais sempre podemos "adicionar" mais espaço em disco. Mas às vezes ... você só precisa mudar as coisas. Se tivermos um sistema de arquivos "ativo" que pode levar horas (ou dias) para copiar, mesmo quando estiver em plena explosão.

  1. Faça um instantâneo do ZFS e transfira para o novo pool na nova máquina. Deixe levar o tempo que for necessário.
  2. Faça um segundo instantâneo e envie-o como um incremental. O instantâneo incremental inclui apenas o conjunto de alterações (muito menor) desde o primeiro, por isso é relativamente rápido.
  3. Depois que o instantâneo incremental for concluído, você poderá transformar o original e recortar para a nova cópia e o seu "tempo de inatividade offline" será reduzido ao mínimo.

Também enviamos nossos dumps zfs pelo BBCP ... isso maximiza a utilização da nossa rede e minimiza os tempos de transferência.

O BBCP está disponível gratuitamente, você pode pesquisá-lo no Google e é uma compilação direta. Basta copiá-lo para o seu/usr/local/bin nas máquinas src e de destino e isso praticamente funcionará.

1
C. Shamis

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 da seguinte maneira:

/#ftp:[email protected]/

ou

/#ftp:[email protected]/

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

Ele possui 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 estiver copiando (acho que é mais rápido também).

1
w-sky

Para @scottpack, resposta da opção rSync

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

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

enter image description here

1
Dinesh Sunny

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

scp -C -c arcfour256 ./local/files.mp3 [email protected]:/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)

1
user57125

Eu não acho que você fará melhor que o scp, a menos que instale placas de rede mais rápidas. Se você estiver fazendo isso pela Internet, isso não ajudará.

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

Se você pode conectar as duas máquinas diretamente usando a Ethernet gigabit, provavelmente será a mais rápida.

1
Brent

Para 100 Mb/s, o rendimento teórico é de 12,5 MB/s; portanto, a 10 MB/s, você está indo muito bem.

Eu também ecoaria a sugestão de fazer rsync, provavelmente através do ssh. Algo como:

rsync -avW -e ssh $SOURCE [email protected]$REMOTE:$DEST

A 100 Mb/s, suas CPUs devem ser capazes de lidar com a criptografia/descriptografia sem afetar significativamente a taxa de dados. E se você interromper o fluxo de dados, poderá retomar de onde parou. Cuidado, com "milhões" de arquivos, a inicialização levará um tempo antes de realmente transferir qualquer coisa.

1
David Mackintosh

Eu encontrei isso, exceto que eu estava transferindo logs do Oracle.

Aqui está o colapso

  • 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 o FTP com grande sucesso (onde um grande sucesso é equivalente a ~ 700Mb/s em uma rede Gb). Se você estiver recebendo 10 MB (o que equivale a 80 Mb/s), provavelmente algo está errado.

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

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

1
Matt Simmons

Aqui está uma referência rápida para comparar algumas técnicas,

  • A Source é uma CPU Intel (R) Xeon (R) de 4 núcleos E5-1620 a 3.60GHz com 250 Mbps e unidade SATA
  • O destino é uma CPU Intel (R) Xeon (E) de 6 núcleos E-2136 a 3,30 GHz com largura de banda de 1 Gbps e unidade SSD

Número de arquivos: 9632, Tamanho total: 814 MiB, Tamanho médio: 84 KiB

  • RSYNC: 1m40.570s
  • RSYNC + COMPRESSÃO: 0m26.519s
  • TAR + NETCAT: 1m58.763s
  • TAR + COMPRESSÃO + NETCAT: 0m28.009s

O comando tar/netcat foi:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -
1
Antares

Se você estiver enviando arquivos MP3 e outros arquivos compactados, não obterá muito com qualquer solução que tente comprimir ainda mais esses arquivos. A solução seria algo que pode criar várias conexões entre os dois servidores e, assim, colocar mais estresse na largura de banda entre os dois sistemas. Quando isso atingir o máximo, não há muito o que ganhar sem melhorar o seu hardware. (Placas de rede mais rápidas entre esses servidores, por exemplo.)

0
Wim ten Brink

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

Eu usei rsync.

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

O procedimento que segui foi este:

  • executado rsync sem -H (levou 9 horas)
  • quando o rsync terminou, sincronizei o diretório cpool e comecei com o diretório pc; Eu cortei a transferência.
  • depois reiniciou rsync com -H sinalizador e todos os arquivos vinculados no diretório pc foram transferidos corretamente (o procedimento encontrou todos os arquivos reais em cpool e, em seguida, vinculados ao diretório pc) ( levou 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. Todo o tempo eu posso verificar o desempenho usando top e top e finalmente transferi 165 GB de dados.

0
Hector

Tentei algumas ferramentas para copiar um arquivo de 1 GB. O resultado está abaixo: HTTP o mais rápido, com o wget -c nc segundo na linha scp mais lento e falhou algumas vezes. Não há como retomar o rsync usando ssh como back-end, portanto, o mesmo resultado. Em conclusão, eu iria para http com wget -bqc e daria algum tempo. Espero que isso ajude

0
Mijo

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

0
Adam Gibbins