Atualmente, tenho dois servidores CentOS. Preciso saber como e qual a maneira mais rápida seria "tar" o diretório de imagens e SCP-lo?

Essa é a maneira mais rápida que acabei de sugerir, porque a tarar está demorando para sempre ... Executei o comando:

tar cvf imagesbackup.tar images

E eu ia dar uma olhada.

Deixe-me saber se existe uma maneira mais rápida. Eu tenho acesso remoto / SSH às duas máquinas.

Em vez de usar o tar para gravar em seu disco local, você pode gravar diretamente no servidor remoto pela rede usando ssh.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

Qualquer sequência que segue o comando "ssh" será executada no servidor remoto em vez do logon interativo. Você pode canalizar a entrada / saída de e para esses comandos remotos através do SSH como se fossem locais. Colocar o comando entre aspas evita qualquer confusão, especialmente ao usar o redirecionamento.

Ou, você pode extrair o arquivo tar diretamente no outro servidor:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Observe a -Copção raramente usada . Significa "mudar para este diretório antes de fazer qualquer coisa".

Ou talvez você queira "puxar" do servidor de destino:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Observe que a <(cmd) construção é nova no bash e não funciona em sistemas mais antigos. Ele executa um programa e envia a saída para um canal e substitui esse canal no comando como se fosse um arquivo.

Eu poderia facilmente ter escrito o acima, da seguinte maneira:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Ou da seguinte maneira:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Ou então, você pode evitar algumas mágoas e usar o rsync:

server1$ rsync -az ./path server2:/destination/

Por fim, lembre-se de que a compactação dos dados antes da transferência reduzirá sua largura de banda, mas em uma conexão muito rápida, a operação poderá levar mais tempo . Isso ocorre porque o computador pode não ser capaz de compactar rápido o suficiente para acompanhar: se a compactação de 100 MB levar mais tempo do que o necessário para enviar 100 MB, será mais rápido enviá-lo sem compactação.

Como alternativa, você pode considerar a tubulação para compactar com gzip (em vez de usar a opção -z) para poder especificar um nível de compactação. Foi minha experiência que, em conexões de rede rápidas com dados compactáveis, o uso de gzip no nível 2 ou 3 (o padrão é 6) fornece a melhor taxa de transferência geral na maioria dos casos. Igual a:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"

Eu ficaria tentado a sincronizá-lo sozinho - ele faz compressão e lida bem com a perda de links.

Se você apenas os aumentar e nada mais, isso desperdiçará toneladas de tempo com apenas um ganho de velocidade mínimo.

Portanto, simplesmente ordenar os arquivos com os comutadores cvf custará efetivamente o tempo necessário para ler todas as imagens de 55 GB e gravá-las novamente em disco. (Efetivamente, será desperdiçado ainda mais tempo, pois haverá uma sobrecarga considerável).

Há apenas uma vantagem que você ganha aqui: a sobrecarga para o upload de muitos arquivos está sendo reduzida. Você poderá obter tempos de transferência mais rápidos se compactar as imagens (mas como acredito que elas já estejam em um formato compactado, isso não ajudará muito). Apenas mais perda de tempo de computação.

A maior desvantagem da transferência de um enorme arquivo de alcatrão por fio é que, se algo der errado, isso pode significar que você precisa recomeçar.

Eu usaria dessa maneira:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

No novo servidor

md5sum /images/* > md5sum_new.txt

E então apenas diff. E como o scp suporta compactação em tempo real, não há necessidade de arquivos separados.

Editar

Manterei as informações MD5, pois foram úteis para o OP. Mas um comentário me atingiu com uma nova visão. Assim, um pouco de pesquisa forneceu essa informação útil. Observe que o assunto aqui é SFTP e não diretamente SCP .

Ao contrário do FTP, o SFTP adiciona sobrecarga à transferência de arquivos. À medida que um arquivo é transferido entre cliente e servidor, ele é dividido em pequenos pedaços chamados "pacotes". Por exemplo, suponha que cada pacote tenha 32 KB. O protocolo SFTP faz uma soma de verificação em cada arquivo de 32 KB à medida que é enviada e inclui essa soma de verificação junto com esse pacote. O receptor obtém esse pacote e descriptografa os dados e, em seguida, verifica a soma de verificação. A soma de verificação em si é "mais forte" que a soma de verificação CRC32. (Como o SFTP usa uma soma de verificação de 128 bits ou superior, como MD5 ou SHA, e como isso é feito em todos os pacotes, há uma verificação de integridade muito granular que é realizada como parte da transferência.) Assim, o protocolo é mais lento (devido às despesas gerais adicionais), mas a conclusão bem-sucedida de uma transferência significa, de fato,

Além da sugestão de md5sum de Pacey, eu usaria o seguinte:

No destino: nc -w5 -l -p 4567 | tar -xvf -

Então na fonte: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Ainda é um tar / untar, e não há criptografia, mas é direto para o outro servidor. Inicie os dois em conjunto ( -w5oferece 5 segundos de graça.) E observe-o. Se a largura de banda estiver apertada, adicione -z ao alcatrão nas duas extremidades.

Um ponto - nem todos os hosts têm o rsync e os hosts podem ter versões diferentes do tar. Por esse motivo, pode-se recomendar como primeira porta de chamada usando o cpio frequentemente negligenciado.

Você pode cpio over ssh para fazer replicação ad-hoc de estruturas de arquivos / diretórios entre hosts. Dessa forma, você tem um controle mais preciso sobre o que é enviado, visto que precisa "alimentar" o cpio, nom-nom. Também é mais portátil para argumentos, o cpio não muda muito - esse é um ponto importante se você estiver cuidando de vários hosts em um ambiente heterogêneo.

Exemplo de cópia / exportação / home e subdiretórios para host remoto:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

O acima copia o conteúdo de / export / home e quaisquer subdiretórios para / export / home no host remoto.

Espero que isto ajude.

Eu você tem acesso ssh, você tem acesso rsync.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

ou

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

Se você receber um erro como "erro rsync: alguns arquivos não puderam ser transferidos (código 23) em main.c (977) [remetente = 2.6.9]", verifique seu usuário e grupos entre os servidores; você pode ter uma incompatibilidade.

Use a opção rsync "-z" se desejar que o rsync comprima a transferência. Esta opção usará mais CPU, mas menos largura de banda, portanto, esteja ciente disso.

Existe uma opção "--progress" que fornece uma porcentagem de transferência, o que é legal se você gosta desse tipo de coisa.

Eles estão em uma rede compartilhada em vez de precisar da Internet para transferir arquivos? NFS ou FTP pode ser muito mais rápido que a sobrecarga do SCP, embora você perca a criptografia durante a transferência.

Ou você sempre pode usar tubos de alcatrão:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, você pode usar 'z' para gzip ou --lzma se o seu tar o suportar.