melhorando o desempenho do backup rsync

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

Além disso, o que seria necessário fazer para escalar essa abordagem para lidar com dezenas de máquinas recebendo essas mudanças?

E se :

• A hora de modificação dos seus arquivos está correta
• Os arquivos não são muito grandes
• Nenhum envio pode ser perdido (ou há algum tipo de processamento de lista de pendências)

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

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

Dá-lhe algo assim:

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 aperfeiçoado, mas você entendeu.

Presumindo que os dados que você está sincronizando ainda não estejam compactados, ativar a compactação (-z) provavelmente ajudará a transferir a velocidade, ao custo de alguma CPU em cada extremidade.

Se você estiver 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 estava fazendo muito passando 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.

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

Quando você está sincronizando como um método de backup, o maior problema que você enfrentará será se você tiver muitos arquivos dos quais está fazendo backup. O Rsync pode lidar com arquivos grandes sem problemas, mas se o número de arquivos dos quais você está fazendo backup for 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, fazer um loop sobre essas partes, por exemplo

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

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

Quanto a ter dezenas de máquinas refletindo essas alterações, depende de quão novo o backup precisa ser. Uma abordagem seria espelhar as alterações do servidor primário para o servidor de backup e, em seguida, fazer com que os outros servidores retirassem suas alterações do servidor de backup por um daemon rsync no servidor de backup inicial e, em seguida, agendando os outros servidores para puxar um pouco momentos diferentes ou fazendo com que um script use ssh sem senha para conectar-se a cada um dos servidores e peça-lhes para fazer uma nova cópia do backup, o que ajudaria a evitar sobrecarregar o servidor de backup inicial - mas se você enfrentar tantos problemas, isso dependerá em quantas outras máquinas você está fazendo uma cópia do backup.

O rsync tem uma maneira de fazer cópias desconectadas . Em outras palavras, o rsync pode (conceitualmente) diferenciar uma árvore de diretórios e produzir um arquivo de patch que você poderá aplicar posteriormente em qualquer número de arquivos 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 aplica o lote a cada um desses destinos usando --read-batch.

Se você mantiver uma cópia local do último estado de sincronização (ou seja, uma cópia da aparência dos espelhos agora) na mesma máquina que o mestre, poderá gerar esse "patch" no mestre sem entrar em contato com nenhum espelho:

No mestre:

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

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

1. Isso fará /current/mirrormudanças para refletir/master/data
2. Ele criará um arquivo de correção binário (ou arquivo em lote) chamado my-batch.rsyncpara uso posterior.

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

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

Benefícios desta abordagem:

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