Posso garantir redundância de dados no servidor quando uso o RSYNC?

Question

Digamos que eu tenha um servidor que forneça serviços de missão crítica, esses serviços dependem de dados que são sincronizados de outro servidor. A questão é sempre que posso garantir a redundância de dados no servidor se para a sincronização de dados eu vou usar o RSYNC?

O RSYNC fornece maneiras de verificar sempre que a sincronização terminar sem qualquer tipo de corrupção de dados (por qualquer motivo)?

Existe uma maneira confiável de retomar a sincronização de um arquivo (do ponto em que foi interrompido) no caso de uma linha descartada ou semelhante? Existe talvez uma alternativa melhor ao RSYNC, que deve ser usado em cenários onde a redundância de dados é crítica?

    

Answer 1

Sua pergunta é um pouco confusa para mim. Se por "redundância", você quer dizer "integridade" - ou seja, "Se eu rsync algo para o meu servidor posso ter a garantia de que é bit-a-bit idêntico ao material de origem?" a resposta é: provavelmente, mas a verificação de integridade é tão boa quanto os métodos de soma de verificação / comparação empregados pelo Rsync. Para mais informações, eu o encaminho para a página man do Rsync (confira o -c e -B options) e a página wiki do Rsync , que discute os algoritmos de comparação usados pelo Rsync.

Com relação a Rsyncs interrompidos : além de verificando o código de retorno do Rsync para determinar se ele foi terminado corretamente (a lista de códigos de saída do Rsync pode ser encontrada aqui ) executar o Rsync novamente é a melhor maneira de verificar se ele foi concluído sem corrupção ou interrupção na primeira vez. O Rsync irá comparar e ignorar quaisquer arquivos que já tenha copiado com sucesso, e irá copiar qualquer coisa nova ou diferente da fonte (isto realiza a mesma coisa que "retomar" uma transferência interrompida). Se o material de origem estiver mudando tão rapidamente que não é possível garantir a consistência entre as duas execuções, o Rsync pode não ser a melhor ferramenta para garantir a sincronização.

Se por "redundância", você realmente quer dizer "redundância" : ou seja, "Eu só quero substituir no servidor de destino se tenho certeza que tenho um cópia intacta dos dados para usar, mesmo se minha transmissão cair ", então a solução seria fazer vários Rsyncs, assim:

1. Rincronize a cópia antiga dos dados do local local 1 para local local 2 - ambos no mesmo servidor ou locais de rede internos que têm um baixo risco de falha de conexão.
2. Execute o passo 1 novamente e verifique se há erros. Isso verifica se você tem duas cópias do conjunto de dados existente que são idênticos.
3. Rsync a cópia remota (nova) dos dados até o local 1.
4. Execute o passo 3 novamente, para garantir que o local 1 contém uma cópia intacta dos novos dados.

Se o passo 4 ou 5     são interrompidos, você pode a) tentar Rsync da fonte remota     novamente, ou b) simplesmente inverta a direção do Rsync no passo 1 e     execute-o novamente, substituindo a cópia (presumivelmente corrompida) do     dados com a cópia "bem conhecida" mais recente do local de backup     na máquina local. Isso garantiria que você tem "redundância", pois você nunca corre o risco de ter apenas uma cópia corrompida de seus dados sem retornar a um conjunto de dados intacto.