Device: /dev/hda, 1 Currently unreadable (pending)

Standard

Se você está recebendo a mensagem no seu arquivo /var/log/messages:

Device: /dev/hda, 1 Currently unreadable (pending)

Podendo ser /dev/sdb ou qualquer outra indicação de disco saiba que o hd em questão está “pensando em ir para o saco”, por isso, já mantenha um de reserva.
E se isto é por parte de um idc, solicite a troca de disco imediatamente.

smartmontools smartctl monitorando o smart de seus hds (by Mr. Morimoto)

Standard

Este artigo funciona em Ubuntu Server e Debian.
Autor: Carlos E. Morimoto -> http://www.hardware.com.br/artigos/monitorar-smart/

É possível monitorar os erros de leitura do HD (mesmo antes dos badblocks começarem a aparecer) usando o SMART, um recurso de monitoramento disponível em todos os HDs modernos, onde a própria controladora monitora o status do HD e disponibiliza um log numa área reservada, que pode ser lida pelo sistema operacional.

No Linux, este recurso é disponibilizado através do “smartmontools“, um pacote disponível nos repositórios da maioria das distribuições e também no http://smartmontools.sourceforge.net/.
Para instalar no UBUNTU ou Debian use:

apt-get install smartmontools mailutils -y
O smartmontools é baseado no “smartsuite”, um pacote mais antigo, que ainda é incluído em algumas distribuições (como no Debian), mas que oferece menos funções e não é mais desenvolvido ativamente.

A maior parte das funções podem ser acessadas usando o utilitário “smartctl“, incluído no pacote. Comece usando a opção “-i”, seguida do device do HD (como em: smartctl -i /dev/hda) para ver informações sobre o drive:

 

Note que neste caso, embora o SMART seja suportado pelo drive, ele está desativado. Antes de mais nada, precisamos ativá-lo, usando o comando:

# smartctl -s on /dev/hda

Para um diagnóstico rápido da saúde do drive (fornecido pela própria controladora), use o parâmetro “-t short“, que executa um teste rápido, de cerca de dois minutos e (depois de alguns minutos) o parâmetro “-l selftest” que exibe o relatório do teste:

# smartctl -t short /dev/hda

 

Sending command: “Execute SMART Short self-test routine immediately in off-line mode”.
Drive command “Execute SMART Short self-test routine immediately in off-line mode” successful. Testing has begun.
Please wait 2 minutes for test to complete.
# smartctl -l selftest /dev/hda

Este comando exibe um relatório de todos os auto-testes realizados e o status de cada um. Num HD saudável, todos reportarão “Completed without error“.

Você pode executar também um teste longo (que dura cerca de uma hora) usando o parâmetro “-t long“. Ambos os testes não interferem com a operação normal do HD, por isso podem ser executados com o sistema rodando. Em casos de erros, o campo “LBA_of_first_error” indica o número do primeiro setor do HD que apresentou erros de leitura, como em:

Nestes casos, execute novamente o teste e verifique se o erro continua aparecendo. Se ele desaparecer no teste seguinte, significa que o setor defeituoso foi remapeado pela controladora, um sintoma benigno. Caso o erro persista, significa que não se trata de um badblock isolado, mas sim o indício de um problema mais grave.

O parâmetro “-H” (health) exibe um diagnóstico rápido da saúde do drive, fornecido pela própria controladora:

# smartctl -H /dev/hda

SMART overall-health self-assessment test result: PASSED

Neste caso, o SMART informa que não foi detectado nenhum problema com o drive. Em casos de problemas iminentes, ele exibirá a mensagem “FAILING“. Este diagnóstico da controladora é baseado em várias informações, como erros de leitura, velocidade de rotação do disco e movimentação da cabeça de leitura.

Um disco “FAILING” não é um local seguro para guardar seus dados, mas em muitos casos ainda pode funcionar por alguns meses. Se ainda não houverem muitos sintomas aparentes, você pode aproveitá-los em micros sem muita importância, como estações que são usados apenas para acessar a Web, que não armazenam dados importantes. Note que, embora relativamente raro, em muitos casos o drive pode realmente se perder menos de 24 horas depois de indicado o erro, por isso transfira todos os dados importante imediatamente.

Você pode ver mais detalhes sobre o status de erro do HD usando o parâmetro “-A“, que mostra todos os atributos suportados pelo HD e o status de cada um. Na sexta coluna (Type) você pode verificar a importância de cada um; os marcados como “Old_age” indicam sintomas de que o HD está no final de sua vida útil, mas não significam por sí só problemas iminentes. Os mais graves são os “Pre-Fail”, que indicam que o HD está no final de sua vida útil.

Na coluna “WHEN_FAILED” (a mais importante), você vê o status de cada opção. Num HD saudável, esta coluna fica limpa para todas as opções, indicando que o HD nunca apresentou os erros:

O número de setores defeituosos no drive (não remapeados) pode ser visto nos atributos “197 Current_Pending_Sector” e “198 Offline_Uncorrectable”, onde o número de bad blocks é informado na última coluna. Em situaçãoes normais, os badblocks não remapeados contém pedaços de arquivos, que a controladora muitas vezes tenta ler por muito tempo antes de desistir.

Em casos extremos, onde existam vários badblocks não marcados, você pode usar o truque de encher o HD com zeros, usando o comando “dd if=/dev/zero of=/dev/hda” para forçar a controladora a escrever em todos os blocos e assim remapear os setores (perdendo todos os dados, naturalmente).

O número de setores defeituosos já remapeados, por sua vez, pode ser acompanhado através dos atributos “5 Reallocated_Sector_Ct” e “196 Reallocated_Event_Count”.

Naturalmente, não basta executar estes testes apenas uma vez, pois erros graves podem aparecer a qualquer momento. Você só terá segurança se eles forem executados periodicamente.

Para automatizar isso, existe o serviço “smartd” (“smartmontools” no Debian), que fica responsável por executar o teste a cada 30 minutos e salvar os resultados no log do sistema, que você pode acompanhar usando o comando “dmesg

No caso do Debian, além de configurar o sistema para inicializar o serviço no boot, você precisa configurar também o arquivo “/etc/default/smartmontools“, descomentando a linha “start_smartd=yes“.

O padrão do serviço é monitorar todos os HDs disponíveis. Você pode também especificar manualmente os HDs que serão monitorados e os parâmetros para cada um através do arquivo “/etc/smartd.conf“.

Comece comentando a linha “DEVICESCAN”. O arquivo contém vários exemplos de configuração manual. Uma configuração comum é a seguinte:

/dev/hda -H -l error -l selftest -t -I 194 -m tux@gmail.com

Esta linha monitora os logs do /dev/hda (erros e testes realizados) e monitora mudanças em todos os atributos (incluindo a contagem de bad blocks e setores remapeados), com exceção da temperatura (que muda freqüentemente) e envia e-mails para a conta especificada sempre que detectar mudanças. Para que ele use apenas o log do sistema, sem enviar o e-mail, remova a opção “-m”.

Para que os relatórios via e-mail funcionem, é preciso que exista algum MTA instalado na máquina, como o Sendmail ou o Postfix. O smartd simplesmente usa o comando “mail” (que permite o envio de e-mails via linha de comando) para enviar as mensagens. No Debian (além do MTA) é necessário que o pacote “mailutils” esteja instalado.

Depois de alterar a configuração, lembre-se de reiniciar o serviço, usando o comando:

# /etc/init.d/smartd restart

ou:

# /etc/init.d/smartmontools

Caso o SMART indique algum erro grave e o HD ainda esteja na garantia, você pode imprimir o relatório e pedir a troca.

A vida útil média de um HD IDE é de cerca de 2 anos de uso contínuo. HDs em micros que não ficam ligados continuamente podem durar muito mais, por isso é saudável trocar os HDs dos micros que guardam dados importantes anualmente e ir movendo os HDs mais antigos para outros micros.

Normalmente, os fabricantes dão 1 ano de garantia para os HDs destinados à venda direta ao consumidor e 6 meses para os HDs OEM (que são vendidos aos integradores, para uso em micros montados). Uma dica geral na hora de comprar HDs é nunca comprar HDs com apenas 3 meses de garantia, que normalmente é dada apenas para HDs remanufaturados.

Nossa recomendação de comando seria:

#/usr/sbin/smartctl -q errorsonly -H -l selftest -l error /dev/sda

Onde sda vai de acordo com sua tabela de discos. Esse comando inclusive reportou em um servidor que gerenciamos a seguinte mensagem:

ATA Error Count: 1
Error 1 occurred at disk power-on lifetime: 1692 hours (70 days + 12 hours)

ou seja, em 70 dias e 12 horas (estimativa feita pelo Smartmontools, nosso disco Morrerá)…

Já nos avisou para substituição do disco em questão.É isso galera, usem e abusem. É gratis!!!

 

Agradecimentos a Carlos E. Morimoto, um mestre em Gnu/Linux 😉

http://www.hardware.com.br/artigos/monitorar-smart/

Gestor de smart trabalha de maneira eficiente no Ubnutu Karmic e revela problemas antes que ocorram

Standard

Uma das coisas que mais gosto no Ubuntu é a sua facilidade de uso e principalmente a forma eficaz que ele gerencia o sistema em si. Estive com um notebook “aposentado” por 4 meses devido a falta do drive de cd-rom (na realidade já não lê nada… rsrsrs). Esperei um bom tempo afim de que uma manutenção fosse realizada (substituição, na realidade era isso) e não consegui achar o bendito drive com preço acessível.

Pensei comigo o que iria fazer, quer fosse um servidor PXE para instalar alguma coisa, quer fosse pegar um drive emprestado (gaveta externa de cd-rom ou cd-rom externo), e nada disso me veio a cabeça.

Pensei em algo mais simples e cheguei a conclusão que instalar o Ubuntu via USB seria a coisa mais simples e amigável do mundo (foi, sem contar a altíssima velocidade, em ver um Celeron 1.5 com 1gb de ram instalado em 12 minutos é de surpreender qualquer peixão).

Após instalar meu bombástico S.O. acabei percebendo que a “aposentadoria” não fez muito bem para o Tux, o smart relatou problemas (coisa que NUNCA iria imaginar, principalmente homem que só vai ao médico quando já está morrendo com dores).

Ao terminar meu upgrade de versão para o Karmic Koala eu startei o S.O. com euforia e ao me deparar com o desktop recebi a notícia de que o disco não estava indo muito bem, por fim, compreendi que apesar da notícia ruim, meu Ubuntu foi mais que um amigo em me avisar o que poderia ocorrer “na calada da noite”!

Segue screenshot:

Este é um sistema amigo, rsrsrs, avisa tudo (mesmo que possa causar uma dorzinha no coração).

Abraços galera!

Fazendo análise de disco e análise básica de um servidor

Standard

dmesg | grep -i err

Irá verificar erros recentes, problemas de RAM, aplicativos gerando qualquer log de erro significativo pro sistema operacional

tail -f -n XXXXX /var/log/messages

Similar ao anterior. XXX é o numero de linhas para trás. Sempre que o servidor travar, procure as ultimas entradas neste arquivo antes do travamento.

hdparm -Tt /dev/sda (sda, sdb, md0… seja qual for seu disco)

Te dá um relatório de leitura e escrita pro seu disco.

Os valores mínimos aceitáveis são:
Timing cached reads superior a 700
Timing buffered disk reads superior a 25

Se estiver inferior, é grande chance de problema no disco.

Faz um “top” e acompanha o parametro “wa” ou “iowait”.

Este parametro é o quanto seu sistema operacional espera por leitura/escrita do disco. Se durante 5 minutos esse parametro se mantiver muito alto (a cima de uns 60-70%), pode indicar sobrecarga do servidor e/ou problema no disco.

Servidor travou. Será que é Firewall?

Não é dificil acontecer. As vezes o firewall pode estar em um nível de segurança muito alto (acontece muito com o CSF), e o servidor barra todo o tráfego sainte. Tente desativar o Firewall por alguns dias. Não é nada bom ficar sem firewall, mas ir por eliminação nunca faz mal. O APF é uma boa alternativa de firewall pra Linux.

Se usar o CSF, nunca esqueça de sempre fazer update nele.

Alugue um KVM remoto

Outra dica nossa, seria pedir a instalação de um KVM remoto. Desta forma você consegue verificar de forma segura a temperatura do processador, gabinete e outros parametros. Quando o servidor travar, você terá acesso total a máquina e poderá investigar uma possível mensagem de erro no sistema (se houver).

É basicamente isso.. Existem muitas variáveis. Principalmente quando muitos clientes rodam aplicações que desconhecemos.

fonte: http://littleoak.wordpress.com/2009/08/14/fazendo-analise-de-disco-e-analise-basica-de-um-servidor/