Suspensão do servidor - perda de dados na reinicialização, análise post mortem

Question

Um servidor de desenvolvimento pelo qual sou responsável (ext3 no raid 5 w / Debian Squeeze) congelou durante o final de semana e fui forçado a redefini-lo, como não respondendo ao acesso de teclado físico / KVM, nenhum dispositivo eth respondendo, etc. Nem mesmo o processo de backup foi executado (Figuras, a única vez que eu não verifiquei a confirmação)

Assim, após a reinicialização, verifica-se que todos os vestígios da atividade disco IO que deveriam ter ocorrido por um período de ~ 24H desapareceram completamente. Os arquivos de log têm uma grande lacuna nas datas e horas. Como se as gravações nunca fossem confirmadas no disco, nenhum processo parecia ter sido executado.

Por sorte, foi um final de semana e nada de valor teria sido perdido e eu não suspeito de um hack.

O que posso fazer em post mortem para este evento - para evitar que isso aconteça novamente? Eu já vi isso acontecer antes em uma máquina completamente diferente rodando o FreeBSD.

Eu estou reunindo as ferramentas de verificação de disco agora - mas deve haver mais coisas acontecendo!

• Opções de montagem: /dev/sda1 on / type ext3 (rw,errors=remount-ro)
• Kernel: Linux dev 2.6.32-5-686-bigmem
• Disco / inodes: 13%/3%

Answer 1

Parece familiar para mim. Você tem um processador Intel? Em caso afirmativo, quais são as configurações do modo verde no BIOS? Seu BIOS está atualizado?

O que o Intel-Microcode-patch faz o seu Debian aplicar durante a inicialização?

Eu tive situações semelhantes em que um R310 congelou (fins de semana em tempos em que nada aconteceu). Isso foi corrigido por uma atualização do microcódigo da Intel (no meu caso, o CentOS 5).

A Dell recomendou uma atualização do BIOS, que, por sua vez, aplicou a mesma atualização de microcódigo.

Em outros casos, tenho visto os estados de sono da Intel-C como responsáveis.

    

Answer 2

Se você não tiver uma mensagem OOPS do kernel a respeito de por que ela foi bloqueada, você não conseguirá resolver problemas muito mais. Você pode ser capaz de configurar o kdump para salvar alguma saída de depuração, caso isso aconteça novamente, e você pode executar o memtest86 ou algum outro diagnóstico de hardware, mas sem mais informações, você não pode avançar.