J'ai un domU Xen fourni par un tiers, fonctionnant sous Ubuntu (10.04, édition serveur, noyau stock -server). Ce serveur exécute Dovecot et Exim4, avec le courrier stocké dans Maildirs, et exécute une pile LAMP assez typique avec la plupart des applications en Perl, et toutes les données stockées soit dans une arborescence de répertoires pleine de fichiers TIFF, soit dans une DB MySQL. Ce serveur fonctionne depuis environ 3 mois pour les applications LAMP, et un mois pour le courrier. Tous les systèmes de fichiers (sauf le swap) sont des Ext3.
Il y a quelques semaines, nous avons soudainement trouvé tout un tas de fichiers TIFF qui n'étaient plus accessibles, comme l'avait noté notre script de sauvegarde (en utilisant rsync). rsync sur l'hôte distant a signalé les erreurs suivantes :
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)...et ainsi de suite. Les fichiers auront été créés soit fin décembre, soit à la date indiquée dans le chemin d'accès, selon la dernière éventualité, car nous avons migré nos données sur cette machine à la fin de l'année dernière. À ma connaissance, aucun processus n'aura écrit dans les fichiers puisque -- seulement lu à partir de ceux-ci.
Tout au long de la journée, nous avons constaté que la liste des fichiers affectés augmentait. Cette nuit-là, nous avons démonté ce système de fichiers (un dispositif de bloc virtuel Xen) et exécuté une commande fsck qui a trouvé et corrigé de très nombreuses erreurs. Les fichiers affectés avaient maintenant disparu. Cependant, la corruption a cessé de se propager une fois le fsck terminé et le système de fichiers remonté.
(Soit dit en passant, pour illustrer le genre de chance que nous avons eu ici, le seul disque contenant notre seule sauvegarde de ces données est mort de façon catastrophique l'après-midi même. Oui, vraiment. Notre seule autre La sauvegarde date du 10 décembre 2010...)
Le fait que la grande majorité des fichiers concernés aient été créés le 4 ou le 5 janvier de cette année n'a peut-être pas d'importance, mais certains étaient des documents de 2006-2007 et d'autres étaient plus récents.
Le fsck étant terminé et la machine apparemment stable, nous étions inquiets - le fournisseur d'hébergement n'a pu trouver la cause première, et nous non plus - et nous avions perdu des données, mais au moins la corruption avait cessé.
Avancez de quelques jours, et une routine mysqldump refuse de vider 3 tables parce qu'elles sont marquées comme écrasées. mysqlcheck confirme cela, et REPAIR TABLE [foo] corrige les 3, en signalant dans 2 cas moins de lignes trouvées après l'événement qu'avant. Encore une fois, le fournisseur ne voit pas de cause profonde, il n'y a pas eu d'interruption de l'alimentation, de l'accès au disque ou de l'accès aux données. mysqld . Le problème ne semble pas lié mais -- en 3 mois d'hébergement sur ce serveur, nous avons déjà perdu plus de données qu'en plusieurs années d'utilisation de ces applications sur une variété de plateformes différentes (mais jamais virtuelles !).
Enfin, cette semaine, nous avons trouvé 3 fichiers sur le FS qui semblent s'être transformés en gunk binaire -- plus précisément, tous les 1 (ou tous les \0xFF si vous préférez). Les 3 fichiers (2 petits fichiers de configuration texte, 1 script de 100 lignes perl) faisaient partie de notre application web, et étaient fréquemment lus mais écrits uniquement lorsque nous déployions une nouvelle version, ce qui fonctionne en mettant à jour une copie de travail locale, en exportant cette copie de travail pour obtenir une nouvelle installation propre, et en pointant un lien symbolique vers cette nouvelle installation. Les fichiers ont été cassés dans la copie de travail et se sont propagés à partir de là, et les temps de modification de tous les fichiers étaient cohérents avec le fait qu'ils n'avaient pas été modifiés depuis de nombreuses semaines (au cours desquelles il y a eu plusieurs déploiements, qui se sont tous déroulés sans problème !
Pour n'importe lequel de ces événements, j'aurais restauré les sauvegardes, je me serais gratté la tête et j'aurais continué ma vie, mais trois en quinze jours me font attendre la suite des événements.
Ma question est simple : est-il possible que ces trois événements soient liés, et si c'est le cas, où dois-je chercher la cause profonde ?
(Les réponses concernant les solutions sont également les bienvenues, mais nous sommes déjà en train de mettre en place une plateforme parallèle exécutant CentOS, sur VMware, avec le même fournisseur, pour essayer d'exclure les problèmes liés à la distribution, au noyau, à l'hyperviseur et au dispositif de bloc virtuel. Ce serait formidable de savoir lequel d'entre eux est à l'origine du problème, mais si nous n'avons pas de diagnostic, et si nous remplaçons toute cette pile qui fonctionne, cela m'aidera à dormir la nuit ... éventuellement).
Comme toujours, si des informations supplémentaires peuvent vous aider, n'hésitez pas à les commenter et je les mettrai à jour !
