Este autoteste SMART indica uma falha na unidade?

10

Gostaria de saber se os resultados deste autoteste SMART indicam uma falha na unidade, esta é a única unidade que apresenta 'concluído: leia falha' nos resultados.

# smartctl -l selftest /dev/sde
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)   LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%      8981         976642822
# 2  Extended offline    Aborted by host               90%      8981         -
# 3  Extended offline    Completed: read failure       90%      8981         976642822
# 4  Extended offline    Interrupted (host reset)      90%      8977         -
# 5  Extended offline    Completed without error       00%       410         -

A unidade ainda não mostra sinais de falha, além da saída desse autoteste SMART. Essa é a saída de uma unidade diferente no mesmo sistema que está executando atualmente um autoteste SMART

# smartctl -l selftest /dev/sdc
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Self-test routine in progress 30%     15859         -
# 2  Extended offline    Completed without error       00%      9431         -
# 3  Extended offline    Completed without error       00%      8368         -


SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       1
  3 Spin_Up_Time            0x0027   176   175   021    Pre-fail  Always       -       4183
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       48
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   088   088   000    Old_age   Always       -       8982
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       46
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       34
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       13
194 Temperature_Celsius     0x0022   111   101   000    Old_age   Always       -       36
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       1
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       2

hard-drive smart

— Jeff Welling
fonte

4

Seria muito mais útil se você executasse smartctl -a /dev/sdee publicasse a seção rotulada SMART Attributes Data Structureque contém contadores brutos. Em particular, o primeiro deles Raw_Read_Error_Rateé o melhor indicador de "unidade defeituosa" (e provavelmente será! 0 no seu caso).

— 31811 Chris S

1

Adicionado. . . . . . . . . .

— 31411 Jeff Welling

1

Os dados que você adicionou parecem bons o suficiente. Se a unidade fizer parte de uma matriz RAID, não me preocuparia. Você deve fazer backup de seus arquivos importantes em primeiro lugar; agora é uma boa hora para começar, se não o fizer.

— 31711 Chris

4

@ Jeff Welling: Não é um pedante sobre isso, mas se o seu "backup" está no array RAID, não é um "backup", é uma "cópia". Pessoalmente, se fosse eu, eu substituiria a unidade por sinal de falha na unidade. Pelo pouco custo que existe até para uma boa viagem hoje em dia, o seguro vale a pena. Além disso, acabei de experimentar duas falhas de unidade, na mesma matriz (RAID10), no mesmo dia. Dos 6 que estavam na matriz. FWIW.

— Kendall

1

@ Kendall, acho que ele quer dizer que o array é usado para backups e os originais estão em outro lugar. Se esse for o caso, eu teria a chance, pois é pouco provável que duas unidades falhem (a menos que sejam novas unidades, a mortalidade infantil é um problema comum e a queima é uma prática comum em grandes matrizes).

— Chris S

8

Espero que você tenha substituído a unidade há muito tempo, mas como ninguém ainda respondeu diretamente à pergunta ...

Você executou dois testes, os quais falharam ao ler o mesmo setor lógico do disco, conforme indicado pelo Completed: read failuremesmo LBA nos dois testes. Na verdade, isso indica que o disco tem um defeito e você poderá substituí-lo na garantia. Tentar armazenar dados nesse setor pode ou não fazer com que a unidade observe que está com defeito durante o processo de gravação e remapeá-lo, mas se a unidade não perceber e não puder ler os dados posteriormente, você perdeu isto.

— Michael Hampton
fonte

4

Vale a pena arriscar seus dados em uma unidade suspeita?

Se fosse eu, eu substituiria a unidade e ficaria agradecido por a SMART me salvar de uma grande dor de cabeça.

— Pedaços de bacon
fonte

Além disso, eu configuraria no mínimo um script cron para executar de forma inteligente uma vez por semana em suas unidades e, em seguida, enviaria a saída em um relatório ou e-mail para você a cada semana, para que você possa, na maioria dos casos, identificar antecipadamente quais unidades podem estar nas últimas etapas para evitar a recuperação de uma falha e a restauração dos backups. Mais fácil ainda, se você tiver várias máquinas, está usando uma ferramenta de monitoramento como Nagios ou Munin.

— Wilshire

5

É mais fácil fazer isso quando você sabe qual saída inteligente indica uma falha na unidade, é difícil dizer o que indica ou não uma unidade com falha.

— Jeff Welling

4

Quero adicionar aos comentários na outra resposta, mas não posso devido à falta de representante, vai entender.

Você não precisa criar um script cron, há um daemon smartd no pacote smartmontools que lida exatamente com o que você deseja fazer: verificação regular do status do SMART. Tudo que você precisa é criar uma configuração e iniciar o serviço. O pacote smartmontools também contém alguns scripts de amostra que o smartd pode chamar quando algo começa a falhar.

— Sgaduuw
fonte

Não estou usando um script cron, estou usando o daemon smartd. Ele lança notas no log do sistema, notei algumas linhas que normalmente não vejo em outras unidades e tentei um autoteste, que quando verifiquei falhou. Eu nunca tinha visto esse tipo de falha antes, então pensei que as pessoas aqui pudessem ter. A saída do syslog do smartd é bastante enigmática se você não tem muita experiência com ele, não diz exatamente "O Drive X está morrendo e precisa ser substituído", mas seria bom se o fizesse :)

— Jeff Welling

2

O que farei na sua situação?

Antes de tudo, descubro quais arquivos são afetados. Há algumas instruções sobre como fazer isso http://smartmontools.sourceforge.net/badblockhowto.html#e2_example1 Sim. No seu caso, é mais difícil porque você tem uma matriz. Mas é possível. Depois, verifique se esse arquivo está em backup e grave zeros no setor com falha. Duas coisas podem acontecer. 1. A unidade grava com sucesso zeros neste setor. Current_Pending_Sector, Reallocated_Sector_Ct deve ser zeros depois. 2. A unidade falha ao gravar neste setor. Do que refaz esse setor para uma área "livre".

De qualquer forma, você acaba com uma unidade fixa. Você deve restaurar seu arquivo do backup (porque você substituiu um setor dele). Além disso, você deve executar novamente um autoteste estendido para garantir que não haja mais erros.

Mantenha-se saudável!

PS: Eu sei que este post é meio antigo. Mas eu tentei. E acho que é uma boa ideia fornecer outra boa resposta.

— Alexandr Priymak
fonte

1

informação útil! Vou tentar isso agora

— kerridge0

0

A unidade provavelmente estava saindo. Ser incapaz de ler parte da unidade é definitivamente uma condição de falha, e certamente é possível que isso aconteça sem outros sinais típicos de falha no disco. Esse tipo de coisa geralmente não é passageiro; sem outros sinais, pode ser uma cabeça fraca, um problema de alinhamento muito leve ou uma área defeituosa em uma bandeja (cilindro?).

A outra alternativa é que houve um bug SMART; você realmente não quer rodar uma unidade com firmware de buggy.

Sempre que você vê algum erro da SMART, é um forte sinal de que você deve obter uma nova unidade para evitar a perda de dados. Pretende-se como um sistema de alerta precoce, em parte.

— Falcon Momot
fonte

0

Faça backup o mais rápido possível!
Se esta unidade ainda estiver na garantia,
- execute a verificação do fornecedor (normalmente você pode obter um CD de inicialização)
- se isso retornar erro, então bingo, envie de volta e aguarde a substituição
- restaurar do backup
- problema resolvido - END

Se esta unidade não tiver garantia, você estará ferrado
- ainda há alguma esperança ...
- como na verdade é apenas um erro de leitura, isso não significa que você não pode gravar nele
- depois de fazer um backup, você pode tentar restaurá-lo, pois ele substituirá setores ilegíveis por novos dados que você poderá ler de volta (bem, geralmente isso funciona, em segundo plano a unidade remapeará esses blocos para poupar setores na maioria das vezes )
- badblocks A ferramenta também pode ser usada para isso (você já possui backups, certo?)
  - na verdade, você não usa isso para testar o disco (não faz muito sentido com os discos nunca), mas para gravar nesses setores várias vezes
- você pode executar novamente os testes inteligentes e há chances de que esses setores ilegíveis "se corrijam"
- problema NÃO resolvido, você só fez a unidade durar mais, provavelmente ela falhará mais rapidamente do que normalmente, talvez em um ano, dependendo do uso, mas ei, os discos são baratos, adquira um novo se seus dados forem importantes para você - END

— cstamas
fonte

1

Os discos rígidos modernos (como desde a virada do século) não funcionam da maneira que você descreveu na seção "sem garantia".

— 31711 Chris

3

Comece com o artigo Bad Sector da Wikipedia . Os discos rígidos abstraem o endereço do setor lógico e mapeiam-no para os setores que acredita serem bons. Alguns utilitários de fornecedores (às vezes SMART, dependendo do que é exposto pela unidade) podem gerar relatórios sobre setores remapeados. Setores defeituosos são detectados em operações de gravação normalmente. Geralmente, uma vez escrito, pode ser lido novamente; é a operação de gravação inicial que geralmente falha em setores defeituosos. Quando um setor é ruim, é ruim para sempre, não há como "corrigi-lo".

— Chris S

1

Acho que não disse nada contra o que você está dizendo, mas esclarei um pouco para torná-lo mais "tecnicamente correto".

— Cstamas

2

Não sei por que as pessoas rejeitaram tanto sua resposta. Eu acho que você está no local. As pessoas provavelmente entenderam mal que você está defendendo a manutenção de uma unidade esquisita em operação. Mas, considerando que o OP é um usuário doméstico, o custo de uma nova unidade pode muito bem ser uma preocupação, mesmo aos preços atuais. Eu sei que essa é uma pergunta bastante antiga, mas de mim, pelo menos, você recebe um +1. ;)

— Markus A.

2

@cstamas: Também posso concordar que sua resposta está correta - se uma unidade sobreviver a uma execução completa de badblocks -w(3x escrita, leitura 3x) sem criar novos setores defeituosos, eu a manterei. Caso contrário, está quebrado demais para ser usado em algum lugar.

— mt_