Sincronizar arquivo ECC com servidor de backup / archive não-ECC

Question

Para arquivamento e backup, criei a seguinte estratégia:

• Servidor 1 (Rede local no escritório) funcionando 24 horas por dia, 7 dias por semana, Linux Ubuntu NAS no DIY Odoid XU4 com Cloudshell 2 e Raid-1 (2x 8TB)
  • este é meu principal backup e arquivamento, diretórios importantes em meus computadores / smartphone etc. são diretamente sincronizados quando estão conectados à rede local ou se eu selecionar arquivos manualmente para arquivamento
• porque este não é um backup verdadeiro (imagine minha casa queima, servidor é roubado), eu tenho outro servidor (2), que é fisicamente (muito) separado do servidor 1
  • este servidor está online apenas uma vez por semana, quando rsyncs todos os dados do servidor 1 ou quando eu preciso executar outras tarefas mais intensivas
  • tem 32 GB de RAM ECC

Eu sei que esta configuração deve ser o contrário, mas o XU4 é bastante silencioso e eu não quero que o servidor monstro funcione 24/7 em minha casa. Eu queria saber o quão ruim esta configuração é em termos de corrupção de dados:
- Eu suponho que o servidor 2 irá sincronizar arquivos, não importando se eles estão corrompidos ou não do servidor 1 (por exemplo, devido à RAM não-ECC no servidor 1)
existe uma abordagem viável para dizer ao servidor 1: apenas sincronizar arquivos que foram alterados de propósito, não sincronizar arquivos corrompidos por erros de RAM. - talvez o servidor 1 possa verificar com o servidor 1, por exemplo: "Eu não tenho conexões ativas atualmente, o arquivo xx ainda é alterado - vamos verificar com o servidor 2 se isso ocorreu devido a um erro de RAM"

Qualquer ajuda apreciada!

    

Answer 1

ECC RAM protege você de alguns erros de memória. Os arquivos que você está transferindo estão no disco. Eles só viajam pela RAM momentaneamente, se forem, quando você os sincroniza com o outro computador. Não tem uma API onde você possa "consultar" erros na memória para um arquivo específico.

Além disso, esse tipo de corrupção geralmente não acontece. O que você deve se preocupar é a corrupção do sistema de arquivos, não a corrupção de memória. E honestamente não há muito que você possa fazer sobre isso. Não há como um software de backup saber se um arquivo está corrompido, porque copia apenas arquivos byte para byte.

Desde que você teste suas restaurações , você está pensando demais em tudo isso. Copie seus arquivos para o servidor remoto, teste restaurações ocasionalmente e durma facilmente.

Como um aparte, você pode querer repensar a cópia para um servidor que você possui. O preço de execução desse servidor, manutenção, correção, links de internet que podem sustentar a largura de banda em ambas as direções, a inconveniência de ter uma peça de hardware em sua casa. Um serviço de backup na nuvem, como backblaze , pode fazer isso por US $ 50 / ano. Você pode colocar terrabytes de dados no Amazon Glacier por tostões por dia, se tiver um software de backup que suporte isso.

Eu costumava ser como você - queria super controle sobre todos os aspectos dos meus backups, etc. Então eu vi a luz há alguns anos e eu tenho um backup no local (geralmente um disco rígido USB que pode ser rapidamente transferido para uma nova máquina no caso de uma falha total de hardware) e um backup na nuvem (minhas coisas pessoais estão no Backblaze, coisas não pessoais no AWS S3 e no AWS Glacier).