Erros de Leitura Fazendo Backup no NFS via rsync

Question

Estou fazendo o backup de uma caixa Linux para um NAS montado via NFS. Estou usando o rsync (como parte de um esquema nos moldes do link com hard-links). Isso é ssh em machine_being_backed_up, inicio meu comando rsync, faz backup de arquivos por cerca de uma hora, e então congela o servidor (por exemplo, precisa ser reinicializado fisicamente; o que é muito inconveniente, pois os servidores em outro prédio do outro lado da cidade leva tempo para reiniciar) o erro no final sendo (com nomes reais anônimos):

some/path/file1.gz
rsync: read errors mapping "/home/some/path/file1.gz": Input/output error (5)
some/path/file2.gz
rsync: read errors mapping "/home/some/path/file2.gz": Input/output error (5)
some/path/file3.gz

Isso provavelmente indica que o disco rígido da máquina que estou tentando fazer backup tem alguns setores defeituosos, correto? Ou poderia esse erro surgir da conexão NFS ser muito lenta ou escolher as opções erradas ao montar a minha unidade NFS (montagem com opções rw, soft, intr)? Existe alguma maneira de fazer esses erros de entrada / saída simplesmente pular / falhar esses arquivos, e não congelar o sistema (então eu não tenho que atravessar a cidade para reiniciar o servidor)?

Atualização: Liguei o SMART ontem e fiz autotestes curtos e longos ontem que não reportaram erros (ontem não pude mencionar isso, pois o longo teste terminou em torno de 7p e o computador caiu por volta da meia-noite para que eu pudesse fazer login até esta manhã quando Eu poderia reiniciar o site).

Também tentei rsync-ing os arquivos em questão para uma partição diferente na mesma unidade e não recebi nenhum erro. Agora estou tentando rsync diretamente para o NAS (em vez de montar o NAS usando NFS).

Atualização (3 de outubro): Mudei o disco rígido para uma máquina diferente e ele tem ~ 2 semanas sem erros. Enquanto na máquina antiga, havia erros diários desse tipo. Eu estou supondo erros de placa-mãe ou memória na outra máquina (não tive tempo para diagnosticar completamente e identificar o problema).

    

Answer 1

O fato de que ele congela fisicamente a máquina indica strongmente que isso é um sintoma de um erro de hardware. Eu não esperaria que setores defeituosos causassem a queda de uma máquina, então pode ser algo menos fácil de diagnosticar.

Para ver se são os discos que são o problema, tente ler os arquivos afetados localmente (faça login via SSH e use cat /home/path.to.file > /dev/null ), mas se isso funcionar, isso não significa necessariamente que a superfície do disco está bem e às vezes legível outros não). Se você ainda não o fez, execute as ferramentas de monitoramento do SMART e observe coisas como a contagem de remapeamento do setor subindo - isso indicará que a superfície do disco não está na melhor forma (alguns setores remapeados não são incomuns com unidades massivas modernas, mas muitos indicam um problema sério).

Poderia ser corrupção do sistema de arquivos, mas novamente eu não esperaria que isso travasse completamente a máquina - ou se fosse tão ruim a ponto de travar o driver do sistema de arquivos eu esperaria uma mensagem de kernel panic no console ao invés da máquina parar. Você pode usar o fsck para verificar isso, mas certifique-se de que tudo que você pode ler atualmente seja feito em backup caso a corrupção seja tão ruim que tentar consertar isso torna as coisas piores (isso é raro, mas eu vi isso acontecer especialmente se você usando um sistema de arquivos experimental ou uma versão beta em vez de uma versão experimentada + testada).

Outra coisa para verificar com o congelamento de hardware é que o CPU e RAM estão bem. Eles podem estar com defeito e superaquecer - não tanto que isso cause um problema na operação normal, seja a carga extra imposta pela execução do rsync por algum tempo empurrando algo além da borda. A execução de um teste de memória e teste "burn in" da CPU pode destacar isso se for o problema. Seu controlador de E / S pode ser um suspeito também da mesma maneira, embora eu não tenha certeza de como você faria para testar isso.

    

Answer 2

Parece que você tem problemas com o sistema de arquivos ou o disco rígido na máquina de origem e está fora do controle de rsync . Tente isto:

$ cp /home/some/path/file1.gz /home/some/path/file1_bak.gz
...

e execute rsync novamente (com novos arquivos) para ver se funciona. Se não, dê uma olhada na opção --exclude ou --exclude-from para fazer backup de todos os dados restantes o mais rápido possível e, em seguida, verifique o status do disco rígido com SMART , execute fsck se necessário .

    

Answer 3

Eu experimentei o mesmo problema e recebi a mesma mensagem de erro ao copiar grandes (multy MB) com rsync e NTFS em Raspbian GNU / Linux 8.0 (jessie ) . O disco funcionou sem minutos antes no Windows. Eu argumentei que o problema pode estar relacionado ao software.

• Primeiro tentei ler o arquivo em seqüência, supondo que a implementação NTFS não estava suportando mmap (2) corretamente. Isso falhou da mesma maneira.
• Tentei então substituir a implementação NTFS baseada em kernel por NTFS-3G . Isso me permitiu copiar o arquivo sem nenhum problema.