Copie arquivos grandes de um servidor Linux para outro

Estou tentando copiar um 75 gigabyte tgz (instantâneo mysql lvm) de um servidor Linux em nosso data center de LA para outro servidor Linux em nosso data center de NY por um link de 10 MB.

Estou recebendo cerca de 20-30 KB / s com rsync ou scp, que varia entre 200-300 horas.

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

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

Eu já vi a dica do túnel tar + netcat, mas meu entendimento é que ele é bom apenas para muitos arquivos pequenos e não atualiza você quando o arquivo é transferido com eficiência.

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

UPDATE: Bem ... pode ser o link afinal :( 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 de instantâneo.

[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

Obtendo o tarball de instantâneo.

[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 administram nossas instalações, o link é rotulado como um link MPLS / Ethernet de 10 MB. (dar de ombros)

Sneakernet Alguém?

Supondo que seja uma cópia única, não creio que seja possível copiar o arquivo para um CD (ou outra mídia) e durante a noite para o destino.

Essa pode ser a opção mais rápida, pois uma transferência de arquivos desse tamanho, por essa conexão, pode não ser copiada corretamente ... nesse caso, você começa novamente.

rsync

Minha segunda opção / tentativa seria o rsync, pois 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 fornecerá algum feedback em vez de ficar sentado e deixar que você pense duas vezes. :-)

Vuze (bittorrent)

A terceira opção provavelmente seria tentar usar o Vuze como um servidor de torrent e fazer com que sua localização remota usasse um cliente bitorrent padrão para fazer o download. Conheço outras pessoas que fizeram isso, mas você sabe ... no momento em que tudo estava funcionando, etc ... Eu poderia ter passado a noite nos dados ...

Depende da sua situação, eu acho.

Boa sorte!

ATUALIZAR:

Sabe, fiquei pensando um pouco mais no seu problema. Por que o arquivo precisa ser um único tarball enorme? O Tar é perfeitamente capaz de dividir arquivos grandes em arquivos menores (para abranger a mídia, por exemplo). Por que não dividir esse tarball enorme em pedaços mais gerenciáveis ​​e depois transferi-los?

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

Primeiro, divida seu arquivo em pedaços de ~ 2 GB:

split --bytes=2000000000 your_file.tgz

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

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

cat your_file* > your_remote_file.tgz

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

(Se eu encontrar tempo, reescreverei o script)

Normalmente sou um grande defensor do rsync, mas ao transferir um único arquivo pela primeira vez, isso não faz muito sentido. Se, no entanto, você estivesse transferindo novamente o arquivo com apenas pequenas diferenças, o rsync seria o vencedor. Se você optar por usar o rsync de qualquer maneira, eu recomendo executar uma extremidade no --daemonmodo para eliminar o túnel ssh que prejudica o desempenho. A página de manual descreve esse modo completamente.

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

O truque do pipe netcat também funcionaria bem. O tar não é necessário ao transferir um único arquivo grande. E o motivo de não notificá-lo quando terminar é porque você não disse. Adicione um -q0sinalizador ao lado do servidor e ele se comportará exatamente como você esperaria.

servidor $ nc -l -p 5000> outfile.tgz

cliente $ nc -q0 server.example.com 5000 <infile.tgz

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

Dê uma chance 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 origem:

tar czf * | netcat target_box 2342

Você pode tentar remover a opção 'z' no comando tar para obter um pouco mais de velocidade, pois o arquivo já está compactado.

O SCP padrão e o Rsync (que usa o SCP) são muito lentos para arquivos grandes. Eu acho que gostaria de usar um protocolo com menor sobrecarga. Você já tentou usar um codificador de criptografia mais simples ou não? Tente procurar a --rshopção do rsync para alterar o método de transferência.

Por que não FTP ou HTTP?

Embora isso adicione um pouco de sobrecarga à situação, o BitTorrent é realmente uma solução muito boa para transferir arquivos grandes. O BitTorrent possui muitos recursos interessantes, como agrupar nativamente um arquivo e somar cada bloco que pode ser re-transmitido se estiver corrompido.

Um programa como o Azureus [agora conhecido como Vuze] contém todas as peças necessárias para criar, servidor e baixar torrents em um aplicativo. Lembre-se de que o Azureus não é a solução mais enxuta disponível para o BitTorrent e acho que também requer sua GUI - existem muitas ferramentas de torrent orientadas por linha de comando para linux.

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

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

Qualquer um deles, aconselho que você divida o arquivo grande em partes menores, em torno de 500 MB Apenas caso haja corrupção durante o transporte.

Quando você tiver pedaços menores, use o rsync novamente ou eu pessoalmente prefiro usar uma sessão privada de FTP seguro e, em seguida, sincronize os arquivos após a conclusão.

Algumas perguntas podem ajudar nas discussões: Quão críticos são os dados a serem transferidos? É para recuperação de desastres, backup quente, 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 sincronizados usando cluster ou atualização via changelogs (eu não sou totalmente versado sobre os recursos de um sistema de banco de dados MySql). Isso pode ajudar a reduzir a quantidade de dados que precisam ser transferidos através do link.

O bbcp dividirá o arquivo para você e copiará com vários fluxos.

Resposta tardia para os googlers:

Ao transferir conjuntos de dados grandes, o rsync pode ser usado para comparar a origem e o destino e 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-o e executa o rsync novamente, usando --read-batch para incorporar as alterações no conjunto de dados remoto.

Se os arquivos de origem mudarem durante o transporte físico ou se a mídia de transporte ficar cheia, você poderá continuar repetindo o --only-write-batch | navio - ciclo de leitura em lote até que o destino seja capturado.

(Ref: eu fui um dos autores desse recurso no rsync - para obter mais informações e casos de uso, consulte esta discussão sobre a implementação do protótipo: https://lists.samba.org/archive/rsync/2005-March/011964 .html )