Copia arquivos grandes de um servidor Linux para outro

Question

Estou tentando copiar 75 gigabyte tgz (instantâneo mysql lvm) de um servidor Linux em nosso datacenter de LA para outro servidor Linux em nosso datacenter de Nova York através de um link de 10 MB.

Estou obtendo cerca de 20-30Kb / s com rsync ou scp, que flutua entre 200 e 300 horas.

No momento, é um link relativamente silencioso, já que o segundo data center ainda não está ativo e obtive excelentes velocidades de pequenas transferências de arquivos.

Eu segui diferentes guias de ajuste de tcp que encontrei via google sem sucesso (talvez eu esteja lendo os guias errados, tenha um bom?).

Eu vi a dica do túnel tar + netcat, mas, no meu entender, ela é boa apenas para LOTES de arquivos pequenos e não atualiza quando o arquivo é efetivamente transferido.

Antes de recorrer ao envio de um disco rígido, alguém tem uma boa entrada?

ATUALIZAÇÃO: Bem ... pode ser o link depois de tudo :( Veja meus testes abaixo ...

Transferências de NY para LA:

Obtendo um arquivo em branco.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Obtendo o tarball do snapshot.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Transferências de LA para NY:

Obtendo um arquivo em branco.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Como criar o tarball do snapshot.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Acho que vou falar com as pessoas que gerenciam nossas instalações. O link é rotulado como um link MPLS / Ethernet de 10MB. (encolher de ombros)

    

Answer 1

Sneakernet Anyone?

Supondo que se trata de uma cópia única, não suponho que seja possível copiar o arquivo para um CD (ou outra mídia) e de um dia para o outro para o destino?

Essa pode ser sua opção mais rápida, já que uma transferência de arquivo desse tamanho, por essa conexão, pode não ser copiada corretamente ... e, nesse caso, você pode começar tudo de novo.

rsync

Minha segunda opção / tentativa seria o rsync, pois ele detecta transferências com falha, transferências parciais, etc., e pode continuar de onde parou.

rsync --progress file1 file2 user@remotemachine:/destination/directory

O sinalizador --progress lhe dará algum feedback em vez de apenas ficar sentado e deixar você para adivinhar a si mesmo. : -)

Vuze (bittorrent)

A terceira opção provavelmente seria tentar usar o Vuze como um servidor de torrent e então ter sua localização remota usando um cliente bitorrent padrão para baixá-lo. Eu sei de outros que fizeram isso, mas você sabe ... no momento em que eles fizeram tudo pronto, etc ... Eu poderia ter passado a noite os dados ...

Depende da sua situação, eu acho.

Boa sorte!

ATUALIZAÇÃO:

Você sabe, eu comecei a pensar sobre o seu problema um pouco mais. Por que o arquivo tem que ser um único tarball enorme? O Tar é perfeitamente capaz de dividir arquivos grandes em arquivos menores (para ampliar a mídia, por exemplo), então por que não dividir esse tarball enorme em partes mais fáceis de gerenciar e depois transferir as peças?

    

Answer 2

Eu fiz isso no passado, com um arquivo de 60GB tbz2. Eu não tenho mais o script, mas deve ser fácil reescrevê-lo.

Primeiro, divida seu arquivo em partes de ~ 2GB:

split --bytes=2000000000 your_file.tgz

Para cada peça, calcule um hash MD5 (isto é para verificar a integridade) e armazene-o em algum lugar, então comece a copiar as partes e seus md5 para o site remoto com a ferramenta de sua escolha (me: netcat-tar-pipe em uma sessão de tela).

Depois de um tempo, verifique com o md5 se suas peças estão bem, então:

cat your_file* > your_remote_file.tgz

Se você também fez um MD5 do arquivo original, verifique também. Se estiver tudo bem, você pode descompactar seu arquivo, tudo deve estar ok.

(Se eu encontrar tempo, vou reescrever o script)

    

Answer 3

Normalmente sou um grande defensor do rsync, mas ao transferir um único arquivo pela primeira vez, não parece fazer muito sentido. Se, no entanto, você estivesse transferindo novamente o arquivo com apenas pequenas diferenças, o rsync seria o vencedor claro. Se você optar por usar o rsync de qualquer maneira, é altamente recomendável executar uma extremidade no modo --daemon para eliminar o túnel ssh que mata o desempenho. A página man descreve esse modo completamente.

Minha recomendação? FTP ou HTTP com servidores e clientes que suportam a retomada de downloads interrompidos. Ambos os protocolos são rápidos e leves, evitando a penalidade do túnel ssh. Apache + wget estaria gritando rápido.

O truque do pipe netcat também funcionaria bem. Alcatrão não é necessário ao transferir um único arquivo grande. E a razão pela qual ele não avisa quando é feito é porque você não contou. Adicione um -q0 ao lado do servidor e ele se comportará exatamente como você esperaria.

server$ nc -l -p 5000 &gt outfile.tgz

client$ nc -q0 server.example.com 5000 &lt infile.tgz

A desvantagem da abordagem do netcat é que ela não permitirá que você continue se sua transferência morrer em 74 GB ...

    

Answer 4

Dê um tiro ao netcat (às vezes chamado de nc). O seguinte funciona em um diretório, mas deve ser fácil o suficiente para ajustar apenas um arquivo.

Na caixa de destino:

netcat -l -p 2342 | tar -C /target/dir -xzf -

Na caixa de fontes:

tar czf * | netcat target_box 2342

Você pode tentar remover a opção 'z' em ambos os comandos tar para ver um pouco mais de velocidade, já que o arquivo já está compactado.

    

Answer 5

Padrão SCP e Rsync (que usa SCP) são muito lentos para arquivos grandes. Eu acho que eu iria olhar para usar um protocolo com menor sobrecarga. Você já tentou usar um cypher de criptografia mais simples ou não? Tente procurar na opção --rsh do rsync para alterar o método de transferência.

Por que não FTP ou HTTP?

    

Answer 6

Embora adicione um pouco de sobrecarga à situação, o BitTorrent é realmente uma ótima solução para a transferência de arquivos grandes. O BitTorrent tem muitos recursos legais, como chilografar nativamente um arquivo e verificar a soma de cada fragmento que pode ser retransmitido se estiver corrompido.

Um programa como o Azureus [agora conhecido como Vuze] contém todas as peças que você precisará criar, server & baixar torrents em um app. O Bean em mente O Azureus não é a solução mais enxuta disponível para o BitTorrent e eu acho que também requer sua GUI - existem muitas ferramentas de torrent baseadas em linha de comando para o Linux.

    

Answer 7

Bem, pessoalmente, 20-30Kb / s parece muito baixo para um link de 10Mb (assumindo 10Mb e não 10MB).

Se eu fosse você, faria uma de duas coisas (supondo que o acesso físico não esteja disponível) -

Qualquer um, eu aconselho você a dividir o arquivo grande em pedaços menores, em torno de 500MB Apenas no caso de corrupção em trânsito.

Quando você tem os blocos menores, use o rsync novamente, ou eu pessoalmente prefiro usar uma sessão segura de ftp privado, e depois CRC os arquivos após a conclusão.

    

Answer 8

Algumas perguntas podem ajudar nas discussões: Quão críticos são os dados a serem transferidos? Isso é para recuperação de desastres, backup ativo, armazenamento offline ou o quê? Você pretende fazer backup do banco de dados enquanto está ativo ou inativo? Que tal configurar um banco de dados no sistema remoto e mantê-los em sincronia usando clustering ou atualização via changelogs (eu não sou totalmente versado nas capacidades de um sistema de banco de dados MySql). Isso pode ajudar a reduzir a quantidade de dados que precisam ser transferidos por meio do link.

    

Answer 9

bbcp irá chunk arquivo para você e copiar com múltiplos fluxos.

    

Answer 10

Resposta tardia para googlers:

Ao transferir grandes conjuntos de dados, o rsync pode ser usado para comparar a origem e o destino e, em seguida, gravar um arquivo em lotes na mídia removível local usando o sinalizador --only-write-batch. Em seguida, você envia a mídia local para o local remoto, conecta-a e executa o rsync novamente, usando --read-batch para incorporar as alterações no conjunto de dados remoto.

Se os arquivos de origem forem alterados durante o transporte físico, ou se a mídia de transporte estiver cheia, você poderá continuar repetindo a opção --only-write-batch | navio | --ciclo de leitura de lote até que o destino esteja totalmente ocupado.

(Ref: Eu fui um dos autores deste recurso no rsync - para mais informações e casos de uso, veja esta discussão sobre a implementação do protótipo: link )