Crash

Dans la nuit du 17 au 18 avril, le disque principal du serveur (partitions "/" et "/home") a rendu l'âme...
Ce disque IBM de 20go équipait le serveur depuis un moment et était évidemment beaucoup sollicité (24h/24 7j/7).

Le lendemain matin en me réveillant, j'allume mon PC pour consulter mon courrier... et pour la première fois depuis longtemps mon client de mail m'annonce une erreur...
Je lance un navigateur web et je parviens à surfer (donc le partage de connexion fonctionne encore).
Par contre impossible de se connecter au serveur... Je me résous à brancher un écran sur le serveur pour regarder ce qui se passe et là je constate qu'il boucle sur des erreurs d'entrées/sorties sur le disque dur !
Comme c'est visiblement mal en point, j'éteins le serveur en le crashant.
Je n'ai pas le temps de m'en occuper (et oui je dois me rendre à un examen de réseau ;)).

En rentrant je démarre une Knoppix que je configure rapidement pour avoir le partage de connexion. Je n'ai pas le temps de faire mieux car je pars le soir même en vacances !
Le disque dur défectueux est maintenant installé sur mon ordinateur personnel.
Une analyse rapide du disque me fait comprendre que le MBR est intact ainsi que la structure des partitions. Par contre le deux superblocks des partitions ext2 sont endommagés :-(.

Au retour des vacances je profite des soirées après le boulot pour analyser un peu mieux les dégats et chercher des solutions.
Un script rapide qui effectue des copies de secteurs répartis sur le disque dur (à l'aide de la commande dd) me permet de chiffrer un peu l'étendu des dégats. Sur la partition de 2go, il y a environ 2500 secteurs défectueux pour 42000000 de secteurs au total. C'est à la fois peu (le disque est faiblement endommagé) et beaucoup (il va y avoir beaucoup de "trous" à combler !).
Pour ne plus travailler sur ce disque défectueux et éviter de perdre encore plus de données, je choisi de faire une image des partitions de ce disque pour bricoler dessus tranquillement.
Mercredi matin je lance la création de l'image de la petite partition ("/" qui fait 2go) depuis une Knoppix vers une de mes partitions windows à l'aide la commande : 
dd if=/dev/hdb2 of=/mnt/hda2/small.img conv=noerror,notrunc,sync bs=512
Cette commande permet donc de faire dans un fichier classique une image du disque dur (comme un ISO pour un CDROM).
Le paramètre "noerror" permet de ne pas bloquer sur les entrées/sorties. Par contre la copie reste tout de même très lente car sur chaque erreurs d'entrées/sorties la copie se bloque et effectue plusieurs tentatives.
En rentrant du boulot le soir je suis donc rassuré de voir que la copie est arrivé à terme... Mais malheur ! Les partitions FAT32 ne supportant pas les fichiers de plus de 2go, l'image du disque n'est pas arrivé à son terme (il manque quelques mégas).
Comme il nous manque de toute façon un disque et de la place pour les données qui sont de plus en plus nombreuse, nous décidons avec mon frère (djakette) d'acheter un nouveau disque de 120go.
Je partitionne ce disque dur au format ext3, je déplace l'image de 2go dessus et heureusement je termine simplement les quelques mégas restants de mon image : 
dd if=/dev/hdb2 of=/mnt/hdd1/small.img conv=noerror,notrunc,sync bs=512 seek=2090000 skip=2090000
La destination a changé (puisque c'est un nouveau disque dur ;)) et à l'aide des paramètres "seek" et "skip" je place le pointeur de lecture et d'écriture au bon endroit pour terminer l'image. En effet le paramètre "notrunc" éviter d'écraser le fichier de sortie :-)
Première bonne nouvelle depuis un moment, je vérifie une chose que j'avais lus quelques jours auparavant : il existe des superblocks de secours répartis un peu partout sur le disque dur !
Je suis donc en mesure de lancer une vérification de l'image du disque en utilisant un des superblocs de secours : 
e2fsck /mnt/hdd1/small_clean.img -y -b 32768
Je lance évidemment la commande sur une copie de l'image (j'ai mis suffisamment de temps à avoir l'original :-)). Le paramètre -b permet de spécifier le superbloc alternatif à utiliser. Le paramètre -y permet de répondre automatiquement au nombre impressionnant de question que va poser e2fsck comme l'image est fortement endommagée.
Une fois cette vérification terminée et un nombre important d'erreurs corrigées, je peux remonter l'image en "loopback" : 
mount /mnt/hdd1/small_crean.img /mnt/small -o loop
Première constatation : l'arborescence de la racine du disque et d'autres répertoires a sauté donc l'intégralité du contenu du disque est passé dans le répertoire "lost+found". Ce répertoire contient donc maintenant une liste impressionnante de fichiers donc le nom a sauté et a été remplacé par '#numero_inode'...
Heureusement les répertoires qui sont dans ce dossier ont leurs sous-répertoires intacts !
Le lendemain matin je lance la copie de la grosse partition (17go) avant de partir en (long) week-end : 
dd if=/dev/hdb3 of=/mnt/hdd1/big.img conv=noerror,notrunc,sync bs=512
Je place en fait cette commande au milieu de deux "date" pour estimer la durée de la copie et la commande se termine par un "halt" pour arrêter la machine. Le tout est logué par un "script" pour que je garde une trace de l'exécution. Je donne comme consigne à ma mère d'éteindre mon PC lorsque le CDROM s'éjectera (comportement de la Knoppix avant le shutdown).

En rentrant de week-end la commande vient juste de se terminer : la copie aura duré plus de 3 jours lol !
Je réalise les mêmes opérations que pour le premier disque : 
e2fsck /mnt/hdd1/big_clean.img -y -b 32768
mount /mnt/hdd1/big_crean.img /mnt/big -o loop
Le résultat est le même que pour la première partition : tout est passé en "lost+found"... Beaucoup de tri en perspective !
Pendant les soirées nous préparons avec mon frère le nouveau serveur : c'est kinder (le Duron 700 réduit au travail de télévision) qui remplacera le serveur. C'est en effet l'occasion de booster le serveur (les copies sur le réseau local était ralenties car le vieux serveur ne suivait pas et le vieux bios ne supportait pas les disques de plus de 32go ce qui nous obligeait à bidouiller).
C'est aussi l'occasion d'installer une distribution Linux mieux adaptée à un serveur : la Mandrake 7.0 est enfin abandonnée et remplacée par une Debian 3.0 :-)
Après avoir reconfiguré la connexion internet, le partage de connexion et autres broutilles du genre, le nouveau (long) week-end qui arrive me permet de commencer le tri !

Je commence par la grosse partition (qui correspondait donc au point de montage "/home") et je retrouve assez facilement des répertoires persos.
Certains sont plus gatés que d'autres :-) Par exemple le répertoire /home/djakette est presque intact alors que le mien n'existe plus et sont contenu est éparpillé parmis les autres "lost+found" :-/
Par une rapide analyse du contenu de chaque dossier je retrouve de cette façon une grande partie des répertoires persos.
Ensuite pour trier les autres dossiers qui ont sauté de l'arborescence je trouve une astuce : les propriétaires des fichiers sont intacts (uid et gid) et par recoupement je retrouve "qui est qui". Ensuite je crée dans chaque dossier perso un répertoire "_backup" dans lequel je met toutes les données récupérées et non triées de l'utilisateur : libre à lui de trier plus tard !

Le tri de la petite partition me prendra en fait autant de temps, voire plus !
En effet les données interessantes à récupérer sur ce disque sont essentiellement les fichiers de configuration et les bases de données.
Je répère le dossier /var/lib/mysql qui contenait les fichiers des bases de données. Visiblement il ne reste plus grand chose, le reste a du partir dans "lost+found" en vrac :-/
Je retrouve rapidement tous les fichiers en utilisant la même technique que pour les utilisateurs : toutes les bases de données apartiennent au même utilisateur Unix.
Par contre le tri est maintenant plus délicat car il faut regarder le contenu des fichiers de base de donnée pour retrouver à qui elles apartenaient.
Autre problème : chaque base de donnée MySQL est composée de 3 fichiers : Le fichier .MYI est facile à reconstruire (un REPAIR TABLE suffit). Le fichier .frm est possible à reconstruire si l'ont connait la structure de la table (c'est ce que je fais pour certaines de mes bases). Par contre lorsque le fichier .MYD manque les données sont vraiment perdues.
Les fichiers de configuration sont plus dur à localiser. Le répertoire /etc a aussi explosé donc tout son contenu est en "lost+found". En fait j'utilise la même technique que pour trier mon dossier personnel : la commande "file" permet de reconnaître le type d'un fichier en analysant son contenu. J'élimine ainsi rapidement tous les programmes executables, les images inutiles etc... Je garde par contre pour un futur tri les fichiers texte.
Par exemple pour remettre l'extension .jpg aux images JPEG et les ranger dans un dossier à part : 
mkdir backup_jpg
file * | fgrep 'JPEG image data' | cut -f1 -d: | while read i; do mv $i backup_jpg/$i.jpg; done
Ou pour rapidement supprimer les programmes executables binaires qui n'ont plus d'intérêt : 
rm `file * | fgrep 'ELF 32-bit LSB executable' | cut -f1 -d:`
Avec ces techniques j'ai réussi à récupérer une quantité importante de données. Certes le disque n'était pas "trop" endommagé.
Je suis surtout surpris de ne pas avoir perdu plus de "gros" fichiers (bases de données par exemple). En effet "statistiquement" les "trous" du disque avaient plus de chance de tomber sur des zones occupées par de gros fichiers. Finalement il semble manquer peu de base de données. Parfois il manque même le fichier de modèle de la base de donnée (quelques kilos) alors que les données (quelques megas) ont survécu !

http://zeRezo.com/ revient donc doucement à la vie à partir du 8 mai. Le downtime aura duré environ 3 semaines. Cette (longue) durée s'explique par les autres activités que j'ai eu ;-)