Transferir 15 TB de pequenos arquivos

Estou arquivando dados de um servidor para outro. Inicialmente, comecei um rsynctrabalho. Levou duas semanas para criar a lista de arquivos apenas para 5 TB de dados e outra semana para transferir 1 TB de dados.

Então tive que interromper o trabalho, pois precisamos de algum tempo de inatividade no novo servidor.

Foi acordado que iremos tará-lo, pois provavelmente não precisaremos acessá-lo novamente. Eu estava pensando em dividi-lo em pedaços de 500 GB. Depois tardisso, eu iria copiá-lo ssh. Eu estava usando tare pigzainda é muito lento.

Há uma melhor forma de fazê-lo? Eu acho que os dois servidores estão no Redhat. O servidor antigo é o Ext4 e o novo é o XFS.

Os tamanhos dos arquivos variam de alguns kb a poucos mb e existem 24 milhões de jpegs em 5 TB. Então, acho que entre 60 e 80 milhões por 15 TB.

edit: Depois de jogar com rsync, nc, tar, mbuffer e pigz por alguns dias. O gargalo será a E / S do disco. Como os dados são distribuídos por 500 discos SAS e cerca de 250 milhões de jpegs. No entanto, agora eu aprendi sobre todas essas boas ferramentas que eu posso usar no futuro.

Eu tive resultados muito bons usando tar, pigz(gzip paralelo) e nc.

Máquina de origem:

tar -cf - -C /path/of/small/files . | pigz | nc -l 9876

Máquina de destino:

Extrair:

nc source_machine_ip 9876 | pigz -d | tar -xf - -C /put/stuff/here

Para manter o arquivo:

nc source_machine_ip 9876 > smallstuff.tar.gz

Se você quiser ver a taxa de transferência, apenas passe pvdepois pigz -d!

Eu me ateria à solução rsync. O rsync moderno (3.0.0+) usa a lista de arquivos incremental, portanto, não é necessário criar a lista completa antes da transferência. Portanto, reiniciar não exigirá a transferência completa novamente em caso de problemas. A divisão da transferência por diretório de primeiro ou segundo nível otimizará ainda mais isso. (Eu usaria rsync -a -Pe acrescentaria --compressse sua rede fosse mais lenta que suas unidades.)

Configure uma VPN (se for a Internet), crie uma unidade virtual de algum formato no servidor remoto (torne ext4), monte-a no servidor remoto e monte-a no servidor local (usando um protocolo em nível de bloco como o iSCSI ) e use dd ou outra ferramenta em nível de bloco para fazer a transferência. Você pode copiar os arquivos da unidade virtual para a unidade real (XFS) conforme sua conveniência.

Duas razões:

1. Sem sobrecarga do sistema de arquivos, que é o principal culpado pelo desempenho
2. Sem procurar, você está olhando para leitura / gravação seqüencial nos dois lados

Se o servidor antigo estiver sendo descomissionado e os arquivos puderem ficar offline por alguns minutos, geralmente será mais rápido retirar as unidades da caixa antiga e conectá-las ao novo servidor, montá-las (novamente on-line agora) e copiar os arquivos para os novos servidores discos nativos.

Use o mbuffer e, se estiver em uma rede segura, você pode evitar a etapa de criptografia.

(Muitas respostas diferentes podem funcionar. Aqui está outra.)

Gere a lista de arquivos com find -type f(isso deve terminar em algumas horas), divida-a em pequenos pedaços e transfira cada pedaço usando rsync --files-from=....

Você já considerou sneakernet? Com isso, quero dizer transferir tudo para a mesma unidade e depois movê-la fisicamente.

há cerca de um mês, a Samsung lançou uma unidade de 16 TB (tecnicamente, é 15,36 TB), que também é um SSD: http://www.theverge.com/2015/8/14/9153083/samsung-worlds-largest-hard -drive-16tb

Eu acho que essa unidade faria quase por isso. Você ainda teria que copiar todos os arquivos, mas como você não possui latência de rede e provavelmente pode usar SATA ou uma técnica igualmente rápida, deve ser bem mais rápido.

Se houver alguma chance de obter uma alta taxa de sucesso ao deduplicar, eu usaria algo como borgbackup ou Attic.

Caso contrário, verifique a solução netcat + tar + pbzip2 , adapte as opções de compactação de acordo com o seu hardware - verifique qual é o gargalo (CPU? Rede? IO?). O pbzip2 se estenderia muito bem em todas as CPUs, oferecendo melhor desempenho.

Você está usando o RedHat Linux, então isso não se aplicaria, mas como outra opção:

Eu tive muito sucesso usando o ZFS para armazenar milhões de arquivos, pois inodes não são um problema.

Se essa era uma opção para você, você poderia tirar instantâneos e usar o zfs para enviar atualizações incrementais. Eu tive muito sucesso usando esse método para transferir e arquivar dados.

O ZFS é principalmente um sistema de arquivos Solaris, mas pode ser encontrado nos illumos (fork de código aberto do OpenSolaris da Sun). Eu sei que também houve alguma sorte em usar o ZFS no BSD e Linux (usando o FUSE?) - mas não tenho experiência em tentar isso.

Inicie um rsyncdaemon na máquina de destino. Isso acelerará muito o processo de transferência.

Você pode fazer isso apenas com tar e ssh, assim:

tar zcf - <your files> | ssh <destination host> "cat > <your_file>.tar.gz"

Ou, se você deseja manter arquivos individuais:

tar zcf - <your files> | ssh <destination host> "tar zxf -"