Diagnosticando a integridade do disco com smartctl

Question

Como você determina se um disco tem problemas usando o smartctl?

Eu tenho um servidor Ubuntu 12.04 usando o software RAID1, que ficou completamente sem resposta. Eu reiniciei, e pendurado na inicialização com a mensagem "/ tmp não está pronto ou não presente", então eu pulei e iniciei um terminal de recuperação manual. Tudo parecia bem, exceto que minha ressincronização de RAID era terrivelmente lenta. No entanto, cat /proc/mdstat não mostrou nenhuma falha real no RAID.

Eu aumentei meu /proc/sys/dev/raid/speed_limit_min seguindo as instruções aqui , mas isso não ajudou muito. Meu array de 1TB está sendo ressincronizado há 30 minutos agora, mas é apenas 0,3% concluído.

Então, instalei smartmontools e verifiquei os discos usando:

sudo smartctl --all /dev/sda
sudo smartctl --all /dev/sdb

Ambos relatam uma saúde "PASSED", mas o sdb também mostra várias linhas como:

Error 83 occurred at disk power-on lifetime: 15147 hours
Error 82 occurred at disk power-on lifetime: 15147 hours
Error 81 occurred at disk power-on lifetime: 15147 hours
Error 80 occurred at disk power-on lifetime: 15147 hours

junto com algum tipo de hex-dump para cada um.

O que isso significa? Devo interpretar esses erros para significar que meu disco sdb está morrendo? Como eu confirmo isso?

Edit: Também relacionado, desde o acidente, eu agora não consigo acessar o servidor SSH. Eu posso acessá-lo muito bem a partir de um terminal físico, e não parece haver nenhuma carga excessiva. Certifiquei-me de que o firewall estava desativado e ainda posso executar ping no servidor, mas ssh myuser@myserver resulta em "Tempo limite da conexão esgotado".

    

Answer 1

Verifique se você fez o backup antes de tudo.

Em relação ao erro / tmp, é um erro conhecido:

link

Re: erros SMART:

Faça um teste longo:   smartctl -t long /dev/sdb

Você pode executar isso a qualquer momento. Vai levar algum tempo. Veja os resultados com smartctl -l /dev/sdb quando terminar.

E, claro, verifique se você fez o backup antes de tudo.

A maior preocupação que eu teria com o que você postou é que você parece ter um súbito cluster de erros (em < 2 anos de atividade para o disco). Uma unidade com falha não deve derrubar seu sistema, no entanto (na verdade, você deve ver muitos outros ruídos nos logs durante o tempo em que ele congelou). Erros ocasionais são bastante normais, muito ao mesmo tempo são motivo de preocupação.

O SMART é útil para o aviso antecipado às vezes , você certamente não pode confiar apenas nele.

Então não faria mal voltar para o backup. Mas eu não acho que você tenha algum motivo para entrar em pânico.

    

Answer 2

Muitos dos atributos na tabela de atributos SMART são indicadores úteis de unidades com falha. Você poderia atualizar sua postagem com a saída de 'smartctl -data -A / dev / sdb'? A tabela de atributos é dependente da unidade, portanto, não posso listar os que serão relevantes, além dos bastante genéricos, como 'Reallocated_Sector_Ct', 'Offline_Uncorrectable', etc. A página da Wikipedia em SMART contém descrições da maioria dos atributos.

O autoteste SMART que quadruplebucky também é útil, mas esses contadores de atributos podem informar imediatamente se uma unidade está falhando. A unidade pode não acionar o aviso geral de integridade do SMART, mas ainda assim estar obviamente fora do caminho

    

Answer 3

Se um dos discos caiu fora do ataque, provavelmente há um motivo. Gostaria de substituir o disco com falha (soa como sdb) e reconstruir para que em vez disso. Para os dados inteligentes.

Há uma grande seção na saída smartctl -a na Estrutura de dados inteligente. Esta é uma grande matriz de palavras e números que informa os limites atuais para testes específicos. Alguns dos grandes que você quer olhar são:

• Raw_Read_Error_Rate (id 1)
• Reallocated_Sector_Ct (id 5)
• Spin_Retry_Count (id 10)
• Reported_Uncorrect (id 187)
• Offline_Uncorrectable (id 198)

Todos estão relacionados a problemas com a superfície do disco (exceto pelo id 10, que está relacionado ao motor do fuso). A superfície do disco provavelmente falhará em todas as coisas na unidade. Se algum deles for anormalmente alto (em centenas ou milhares), você tem certeza de que há um grande problema.

Os registros na parte inferior são parecidos com isto:

ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

Nesse caso, houve um erro UNC no disco (erro de leitura / gravação incorrigível).

Minha opinião é que, se você vir algo assim:

Error 518 occurred at disk power-on lifetime: 16859 hours

... o disco deve ser substituído quando for conveniente.

O problema do SSH pode estar relacionado ao disco (pode ser que a parte corrompida esteja sob o binário do SSH), mas isso provavelmente é algo que você deve investigar separadamente.

    

Answer 4

Com relação ao seu backup - aguardar um erro ou aviso SMART é tarde demais para fazer o backup. As práticas recomendadas incluiriam um plano de backup testado, além de redundância suficiente no subsistema de armazenamento para lidar com falhas antecipadas de hardware.