Eu tenho um domu Xen fornecido por terceiros, executando o Ubuntu (10.04, edição do servidor, kernel do servidor de ações). Este servidor executa Dovecot e Exim4, com correio armazenado em Maildirs, e executa uma pilha LAMP bastante típica com a maioria dos aplicativos em Perl, e todos os dados armazenados em uma árvore de diretórios repleta de arquivos TIFF ou em um banco de dados MySQL. Este servidor tem sido operado por cerca de 3 meses para material LAMP e um mês para envio de e-mail. Todos os sistemas de arquivos (exceto swap) são Ext3.
Algumas semanas atrás, de repente, encontramos um monte de arquivos TIFF que não estavam mais acessíveis, como notado pelo nosso script de backup (usando o rsync). rsync no host remoto relatou os seguintes erros:
rsync: readlink_stat("/srv/data/documents/archive/pdf/2007/Aug/06/085717/00000002.TIF") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2007/Aug/06/085717/00000001.TIF") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/XSMDESC.DAT") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/DOC010.XST") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/00000001.TIF") failed: Input/output error (5)
... e assim por diante. Os arquivos serão criados no final de dezembro ou na data indicada no caminho, o que ocorrer depois, à medida que migramos nossos dados para essa máquina no final do ano passado. Nenhum processo, até onde eu saiba, terá sido gravado nos arquivos desde então - apenas leia a partir deles.
Durante esse dia, notamos que a lista de arquivos afetados aumentava, então, naquela noite, desmontamos esse sistema de arquivos (um Xen Virtual Block Device) e executamos um fsck , que encontrou e corrigiu muitos, muitos erros. Os arquivos afetados foram embora agora. No entanto, a corrupção parou de se espalhar assim que o fsck foi concluído e o sistema de arquivos remontado.
(Como um aparte, para ilustrar o tipo de sorte que tivemos aqui - o único disco segurando nosso único backup desses dados morreu catastroficamente na mesma tarde. Sim, realmente. Nosso único outro backup foi de 10 de dezembro de 2010 ...)
Pode ou não ser relevante que a grande maioria dos arquivos afetados tenha sido criada em 4 ou 5 de janeiro deste ano - no entanto, alguns eram documentos de 2006/7, e alguns eram mais recentes.
Com o fsck completo e a máquina agora aparentemente estável, ficamos preocupados - o provedor de hospedagem não encontrou nenhuma causa, e nem nós - e nós perdemos dados, mas pelo menos a corrupção parou.
Avança vários dias, e uma rotina mysqldump se recusa a despejar 3 tabelas porque elas estão marcadas como falhas. mysqlcheck confirma isso, e REPAIR TABLE [foo] corrige todos os 3, em 2 casos relatando menos linhas encontradas após o evento do que antes. Novamente, o fornecedor não pode ver nenhuma causa raiz, não houve interrupção na alimentação, acesso ao disco ou mysqld . O problema parece não estar relacionado, mas - em 3 meses de hospedagem neste servidor, já perdemos mais dados do que em vários anos de execução desses aplicativos em uma variedade de plataformas diferentes (mas nunca virtuais!).
Finalmente, nesta semana, encontramos 3 arquivos no FS que parecem ter se transformado em gunk binário - mais especificamente, todos os 1s (ou todos %code%xFF , se você preferir). Todos os 3 arquivos (2 pequenos arquivos de configuração de texto, 1 script 100-ish line perl) faziam parte do nosso aplicativo web e eram lidos com frequência, mas escritos apenas quando implantamos uma nova versão, que funciona atualizando um "trabalho" local copie, exporte essa cópia de trabalho para obter uma instalação limpa e recente e aponte um link simbólico para essa nova instalação. Os arquivos foram quebrados na cópia de trabalho e propagados a partir daí, e os tempos de modificação em todos os arquivos foram consistentes com eles não terem sido alterados por muitas semanas (em que houve diversas implementações, todas correram bem!) conteúdo claramente alterado sem que o mtime seja atualizado.
Qualquer um desses eventos me faria restaurar de backups, coçando minha cabeça e continuando com a minha vida, mas 3 em quinze dias me espera para a próxima coisa acontecer.
Minhas perguntas são simples: é possível que esses três eventos estejam conectados e, em caso afirmativo, onde devo procurar uma causa raiz?
(As respostas sobre soluções também são bem-vindas, mas já estamos no processo de configurar uma plataforma paralela rodando o CentOS, na VMware, com o mesmo fornecedor, para descartar problemas relacionados a distribuição, kernel, hipervisor e dispositivo de bloco virtual Seria ótimo saber qual deles era o problema, mas se não tivermos um diagnóstico, e substituindo todo o stack, isso vai me ajudar a dormir à noite ... eventualmente.)
Como sempre, se alguma informação extra ajudar, por favor, comente e eu atualizarei de acordo!