melhorando o desempenho do backup do rsync

Question

Quais são as melhores técnicas para melhorar o rsync em relação ao espelhamento ssh entre as caixas unix, assumindo que um sistema sempre terá a cópia principal e o outro sistema sempre terá uma cópia recente (menos de 48 horas)

Além disso, o que alguém teria que fazer para dimensionar essa abordagem para lidar com dezenas de máquinas que receberam um empurrão dessas mudanças?

    

Answer 1

Se:

• A hora da modificação dos seus arquivos está correta
• Os arquivos não são realmente grandes
• Nenhum push pode ser perdido (ou há algum tipo de processamento de backlog)

Você pode usar find -ctime ou file -cnewer para criar uma lista de arquivos alterados desde a última execução e copiar somente os arquivos modificados (apenas um empurrão diferencial glorificado).

Isso se traduziu muito bem para vários hosts: basta fazer um tar diferencial na fonte e descompactá-lo em todos os hosts.

Isso lhe dá algo parecido com isso:

find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt 
for HOST in host1 host2 host3 ...
do
    cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done

O script foi refinado, mas você entendeu.

    

Answer 2

Supondo que os dados que você está rsyncing não estão compactados, ativar a compactação (-z) provavelmente ajudará na velocidade de transferência, ao custo de alguma CPU nos dois lados.

    

Answer 3

Se você está transferindo arquivos muito grandes com muitas alterações, use as opções --inplace e --whole-file, eu as uso para minhas imagens de VM de 2Gb e isso ajudou muito (principalmente porque o protocolo rsync não era t fazendo muito com a passagem de dados incrementais com esses arquivos). Eu não recomendo essas opções para a maioria dos casos.

use --stats para ver como seus arquivos estão sendo transferidos usando o protocolo incremental rsync.

    

Answer 4

Outra estratégia é tornar o ssh e o rsync mais rápidos. Se você estiver passando por uma rede confiável (leia-se: particular), a criptografia da carga real não será necessária. Você pode usar o HPN ssh . Esta versão do ssh criptografa apenas a autenticação. Além disso, o rsync versão 3 inicia a transferência de arquivos durante a criação da lista de arquivos. Isso, claro, é uma enorme economia de tempo em relação à versão 2. do rsync. Não sei se é isso o que você estava procurando, mas espero que ajude. Além disso, o rsync suporta o multicast de alguma forma, embora eu não pretenda entender como.

    

Answer 5

Quando você está rsyncing como um método de backup, o maior problema que você enfrentará será se você tiver muitos arquivos que você está fazendo backup. O Rsync pode manipular arquivos grandes sem problemas, mas se o número de arquivos que você estiver fazendo backup ficar muito grande, você notará que o rsync não será concluído em um período de tempo razoável. Se isso acontecer, você precisará dividir o backup em partes menores e, em seguida, repetir essas partes, por exemplo,

find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/

ou tarring o conjunto de arquivos para reduzir o número de arquivos.

Quanto a ter dezenas de máquinas recebendo um espelho dessas mudanças, isso depende de quão fresco o backup precisa ser. Uma abordagem seria espelhar as alterações do servidor primário para o servidor de backup e fazer com que os outros servidores retirem as alterações do servidor de backup por um daemon rsync no servidor de backup inicial e, em seguida, agendando os outros servidores para um pouco vezes diferentes ou usando um script para usar o ssh sem senha para se conectar a cada um dos servidores e pedir que eles peguem uma nova cópia do backup, o que ajudaria a evitar sobrecarregar o seu servidor de backup inicial - mas se você vai a esse problema vai depender em quantas outras máquinas você tem puxando uma cópia do backup.

    

Answer 6

O rsync tem uma maneira de fazer cópias desconectadas . Em outras palavras, o rsync pode (conceitualmente) diff uma árvore de diretórios e produzir um arquivo patch que depois você pode aplicar em qualquer número de arquivos que são idênticos à fonte original.

Requer que você invoque o rsync com o mestre e espelhe com --write-batch ; produz um arquivo. Em seguida, você transfere esse arquivo para qualquer número de outros destinos e, em seguida, aplica o lote a cada um desses destinos usando --read-batch .

Se você mantiver uma cópia local do último estado rsynced (ou seja, uma cópia do que os espelhos parecem agora) na mesma máquina que o mestre, você pode gerar este "patch" no master sem sequer entrar em contato com qualquer espelho :

No mestre:

rsync --write-batch=my-batch.rsync /master/data /current/mirror

Adicione as outras opções desejadas. Isso fará duas coisas:

1. Isso fará com que /current/mirror mude para refletir /master/data
2. Ele criará um arquivo de patch binário (ou arquivo em lote) chamado my-batch.rsync para uso posterior.

Transfira o arquivo my-batch.rsync do mestre para todos os seus espelhos e, em seguida, nos espelhos, aplique o patch , por assim dizer:

rsync --read-batch=my-batch.rsync /local/mirror

Benefícios desta abordagem:

• o mestre não está sobrecarregado
• não há necessidade de coordenar / ter acesso ao master / mirror (s) ao mesmo tempo
• pessoas diferentes com privilégios diferentes podem fazer o trabalho no mestre e no (s) espelho (s).
• não há necessidade de ter um canal TCP (ssh, netcat, seja o que for; o arquivo pode ser enviado via e-mail ;-))
• espelhos off-line podem ser sincronizados mais tarde (basta colocá-los on-line e aplicar o patch)
• todos os espelhos são idênticos (já que aplicam o mesmo "patch")
• todos os espelhos podem ser atualizados simultaneamente (já que o --read-batch é apenas cpu / io intensivo no próprio espelho)