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

Preciso transferir uma enorme quantidade 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, scpmas 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?

Eu recomendaria alcatrão. Quando as árvores de arquivos já são semelhantes, o rsync executa muito 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

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

Eu usaria rsync.

Se você os exportou via HTTP com 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 na 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/

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 -

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 de recursão incremental .

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 tenham sido encontrados) e requer muito menos memória. Veja a opção --recursive na página de manual para algumas restrições.

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 user@host:/remote/path

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

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

e mudou para tar...

# 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, o que está fazendo o push. Não torne ainda mais rápido, decidimos não preservar os atimearquivos:

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 idéia do meu chefe e meu colega a executou e fez a excelente redação em seu blog . Eu apenas gosto de fotos bonitas . :)

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 postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

Também uso o tar através da netcatabordagem, 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 os socatargumentos mais fáceis de lembrar 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.

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

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'

• Network File System (NFS) e copie-os com o que quiser, por exemplo, Midnight Commander (mc), Nautilus (do gnome). Eu usei o NFS v3 com bons resultados.
• Samba (CIFS) e, em seguida, copie os arquivos com o que você quiser, mas não tenho idéia de como é eficiente.
• HTTP com wget --mirrorcomo 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 . Eu o usei com bons resultados e um de seus recursos interessantes é que você pode interromper e retomar a transferência posteriormente.

Notei que outras pessoas recomendaram o uso do netcat . Com base na minha experiência , posso dizer que é lento em comparação com as outras soluções.

Graças à maravilhosa resposta de Scott Pack (eu não sabia como fazer isso com o ssh antes), posso oferecer essa melhoria (se bashfor 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 [user@]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 -9ee pxz -dse você tiver muito mais CPU do 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 [user@]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 eu copio sistemas de arquivos dessa maneira, geralmente irei dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefszerar a maior parte do espaço não utilizado, o que acelera o xfer.

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 o rsync . Pode não ser mais rápido, mas pelo menos se falhar (ou você o desligar porque está demorando muito tempo), você pode 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.

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 $USER@$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.

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.

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 é o 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.
• Ele gzip -1fornece 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 canais em paralelo e realmente garantir que você está saturando sua 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:

• Seja como for que você transfira, provavelmente executaria um rsync ou uníssono depois para garantir que você tenha tudo.
• Você poderia usar em tarvez de, cpiose preferir.
• Mesmo que você acabe usando o ssh, eu garantiria que ele não esteja usando nenhuma compactação em si e percorreria gzip -1você mesmo para evitar a saturação da CPU. (Ou pelo menos defina o CompressionLevel como 1.)

Um scp simples com opções apropriadas alcançará facilmente 9-10 MB / s através da 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)

Se você tiver um servidor ftp no lado src, poderá usar o ncftpget no 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

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 despejos 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á.

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", digitando o endereço da seguinte maneira:

/#ftp:name@server.xy/

ou

/#ftp:name@ip.ad.dr.ess/

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).

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

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 para tar / netcat era:

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

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.

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. Uma vez que isso chegue ao limite, não há muito o que ganhar sem melhorar o hardware. (Placas de rede mais rápidas entre esses servidores, por exemplo.)

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 com falha algumas vezes. Nenhuma maneira de retomar o rsync usa ssh como back-end, portanto, o mesmo resultado. Em conclusão, eu iria para o http com wget -bqc e daria algum tempo. Espero que isso ajude

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 rsyncsem -H(levou 9 horas)
• quando o rsync terminou, sincronizei o cpooldiretório e comecei com o pcdiretório; Eu cortei a transferência.
• em seguida, reiniciado rsynccom o -Hsinalizador e todos os arquivos vinculados no pcdiretório foram transferidos corretamente (o procedimento encontrou todos os arquivos reais no diretório cpoolvinculado ao pcdiretório) (levou 3 horas).

No final, pude verificar se df -mnão foi gasto espaço extra.

Dessa maneira, 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.