Malheur de l’administrateur système, je supprime par erreur (je vus le jure) le répertoire /var d’un serveur… et vous imaginez la suite… Primo seule ma session SSH encore ouverte peut être utilisée, et personne n’a accès au serveur physiquement, puisque c’est un hébèrgement distant. Pas de sauvegarde, plus de base mysql… je panique… Mais par chance le disque est en reiserfs. Vous allez donc voir comment on peut espérer récupérer une grosse partie des données après un “rm -rf /var/*” malencontreux.

Démonter le disque

Il faut démonter le disque avec la commande umount.Et si on n’a pas le choix, comme pour moi qui avait /var dans la partition racine, tant pis on continue, mais on va avoir plus de perte. Là l’essentiel et de tenter le tout pour le tout.

Donc, si vous n’êtes pas dans mon cas, faites: mount (on regarde si le répertoire viré est un point de montage, on note le nom du disque, par exemple /dev/sda3, et on continue) umount /dev/sda3

A partir de là, on va faire deux choses: -image de la partition -un coup de reiserfsck pour réparer.

Faire l’image du disque

Pour récuperer les données, il ne faut pas faire une simple copie… si nous faisions cela, nous récupérions seulement les fichiers non touchés. Or nous voulons les fichiers effecés. ReiserFS ne supprime par réellement les noeuds mais efface leur correspondance dans la table d’allocation du disque. Donc il faut récupérer une image du disque “bit à bit”. La commande dd va nous y aider. Il faut copier l’image sur un disque non touché par notre problème. J’utilise donc /home monté sur un autre disque.

dd if=/dev/sda3 of=/home/user1/imagevar

Cela peut prendre du temps, vous pouvez ajouter l’option ‘‘bs’ en spécifiant la taille des blocs à récuperer à chaque coup.Il ne faut pas dépasser la taille du tampon, pour le coup je ne connaissais pas la taille du cache disque, alors j’ai laissé tel quel. 10 minutes pour copier 7.8Go

Alors, pour ceux qui serait surpris d’avoir une taille d’image très supérieur à l’espace utilisé: je vous rappelle que nous récupérons le disque complet, donc la taille de la partition. Une image d’un disque de 300Go dont vous utilisiez 30Mo fera 300Go et puis c’est tout !

Bon, on passe à la suite. Mon serveur n’ayant plus de /var, pas moyen de faire “apt-get” poru chopper l’outil “reserfsck” (contenu en général dans un paquet nommé resierfs-utils). Donc je transfère ça sur un serveur via SFTP, et je continue.

On répare

J’ai donc mon image sur une Fedora 5 dont j’ai installé reiserfsck avec la commande yum install reiserfs-utils. Reste à utiliser l’outil.

La page de man (man reiserfsck dans la console) indique deux options qui vont me servir. La première –rebuild-tree. Elle est violente et dit qu’elle va reconstruire l’arborescence du disque, y compris avec les blocs qui ont été supprimés. Et l’autre option -S va prendre en compte la partie non utilisé du disque (et oui, parce que c’est certainement là dedans que se trouve nos données).

Reste l’option -l pour faire un log de ce qu’il se passe.

reiserfsck --rebuild-tree -S -l /root/rebuild.log /tmp/imagevar

Théoriquement, cette commande devrait être faire sur un disque non monté. Or là j’ai une image… c’est pareil :)

L’outil me demande de répondre “Yes” après m’avoir prévenu que je risque de tout péter, de déclarer la guerre à la russie et que je peux avoir des maladies en mangeant trop gras… qu’à cela ne tienne…

Long process de récup, il finit par me dire qu’il a rapatrié pas mal de chose. Le log est monstrueux, je ne le lis même pas ;)

Voyons maintenant ce qu’il se passe si je monte mon image: mkdir /tmp/recovervar mount /tmp/imagevar /tmp/recovervar ll /tmp/recovervar/var

Et là, je vois tous mes répertoires de retour… et puis un nouveau répertoir nommé (intelligemment) lost+found. Effectivement, l’arborescence est recréée, mais j’ai quelques fichiers vides. Ces fichiers doivent se trouver dans lost+found mais avec un nom imbuvable. On pourra s’en servir un de ces 4, mais là n’est pas la question, il me faut au moins mes données MySQL, et je retrouve mon /var/lib/mysql ainsi que les bases en binaire.

Récupération en retour

Allez, je fais un gros tar.bz2 (qui me réduit mes 9.8 Go en 747Mo) et je rebalance ça sur la machine à réanimer. (heureusement que la connexion n’est pas tombée).

cd /tmp/recovervar/ tar cvfj recovervar.tar.bz2 ./var

Voilà, le bz2 est sur mon /home. Assez de place, je décompacte et je copie: tar jxvf /home/user1/recovervar.tar.bz2 [...] #on remonte le disque si nécessaire mount /var (dans mon cas, je n'ai pas put démonter) cp -a /home/user1/var/* /var/

Je tente une connexion SSH depuis une autre console, et là le miracle opère, ça marche. Donc en premier lieu, l’arbre est bien repris. Reste à relancer MySQL… Argggg… non marche pas.

Un tour dans les logs, je me rend compte que les tables de la base nommée “mysql” (base système pour les droits, etc…) est morte.

Pas grave… vraiment ! En premier lieu j’édite /etc/mysql/my.cfg et je dit que datadir est sur /tmp/mysql mkdir /tmp/mysql chown mysql:mysql /tmp/mysql mysql_install_db ll /tmp/mysql/mysql (oui, deux fois mysql)

Et voilà les bases… on les copie dans /var/lib/mysql/ avec rm -rf /var/lib/mysql/mysql && cp -a /tmp/mysql/mysql /var/lib/mysql/

• • On réédite le fichier /etc/mysql/my.cfg et on remet /var/lib/mysql pour datadir**, sinon on va me dander pourquoi on a plus DU TOUT de données… c’est parce qu’on a pas remis la configuration de mysql correctement ! Le but était simplement de reconstruire les bases par défauts de mysql. Ensuite on les déplace dans le bon répertoire et on remonte mysql sur celui-ci… c’est pas clair ? ba…faites le quand même…

Finalement /etc/init.d/mysql start et c’est repartit (après avoir tué les process rémanents de mysql).

Quelques “repairs” sur les tables pour reprendre les index, et tout (ou presque) st rentré dans l’ordre.

Bilan

Il est clair que si vous avez accès physiquement au serveur, vous pourriez le faire avec un CD dit de “recover” qui permettrait d’avoir accès au disque en boutant sur ce CD. Or là , on est dans le pire des cas… c’est à dore comme beaucoup qui comme moi loue un serveur.

Cela ne fonctionne qu’avec un disque ReiserFS. Ext3 ne permet pas ce genre de chose. Secondo, pensez bien que l’image, y compris après la reconstruction, sera largement plus grande que l’espace que vous utilisiez. Il faut donc plutôt penser à vérifier après coup les fichiers récupérés et réfléchir quant à leur utilité.

N’oubliez jamais d’utiliser cp -a et non pas un simple cp -r. L’intérêt étant de garder les attributs de fichier lors de la copie. Pendant que j’y pense, le répertoire que vous compressez (si vous souhaitez comme moi l’importer ailleurs pour travailler) ne doit ABSOLUMENT PAS être ne .zip. Justement, tar garde les attributs de fichiers.

Un dernier conseil, ou une remarque, démontez le disque **plus tôt possible dés que vous avez repérer la suppression** car plus vous attendez, plus le système écrira sur les blocs non alloués (où se trouve vos données perdues donc)

• • Sachez enfin que cette solution ne vaut pas une sauvegarde bien pensée.** Il faut utiliser le recover d’image qu’en dernier recours. Pour plus d’informations:

http://pwet.fr/man/linux/administration_systeme/reiserfsck http://antrix.net/journal/techtalk/reiserfs_data_recovery_howto.comments?parent=74-1&title=Re:%20Re:%20ReiserFS%20undelete/data%20recovery%20HOWTO