Je commencais à songer à aller me coucher quand je me pris à vouloir tenter le diable. Et pourquoi ne pas faire comme le teenager devant le Virgin Megastore à 3 heures du matin pour acheter le dernier album de son artiste préféré, pourquoi donc ne pas tenter de faire une upgrade en Karmic Koala fraichement poussée dans les repos par les joyeux lurons de Canonical quelques heures plus tôt ?

Aussitôt dit, presque aussitôt fait (il faut s’armer de patience lors d’un landrush), je me retrouvais trois heures plus tard avec la dernière mouture en date. Après le reboot réglementaire, je m’appretais à utiliser fièrement mon Gnome 2.28 fraichement déployé lorsqu’une icone vint troubler mon attention: elle m’invitait à prendre connaissance de l’état de mon disque dur. Je cliquais donc.

Cela m’a surpris au début. J’ai cru à un faux positif, comme en réservent souvent les packets nouvellement poussés en production (sur ubuntu en tout cas, il est chez Red Hat depuis un moment). Pour vérifier ses dires, j’ai redémarré et accédé à la partition de diagnostic Dell. Vérification RAM, CPU, et ainsi de suite: PASS, et sur le disque: FAILED. Vraisemblablement le test de surface génère beaucoup d’erreurs.

Comme j’avais bidouillé les drivers SATA/AHCI je me suis dit que cela pouvait venir de cela. Après avoir testé par l’OS (donc par la S.M.A.R.T puis par le diagnostic-tool de Dell), je décidais de descendre d’un niveau en utilisant l’utilitaire du constructeur appelé ES Tool. Après l’avoir gravé, je lançais l’utilitaire (CD amorcable, aucun système ne doit évidemment être loadé pour le diagnostic): même résultat. J’avais bien bons nombres de secteurs défectueux, ou en tout cas en attente de réallocation.

On était donc jeudi soir, j’avais évidement beaucoup de choses à faire pour le boulot le vendredi, mais en même temps on ne plaisante pas avec un disque dur qui commence à claquer, d’autant plus lorsqu’il contient tous les documents importants du boulot et avec une criticité parfois élevée. Alors oui j’avais bien fait des sauvegardes, mais comme la plupart du temps, elles n’étaient pas fondamentalement tenues à jour (cela ne se comptait pas en trimestre non plus, n’exagérons rien).

J’ai donc utilisé ma journée du vendredi à recenser tout ce que j’avais à sauvegarder après avoir monté mes partitions au travers d’un livecd. J’ai tenté au mieux de minimiser les accès disque même si consulter les dossiers génère son petit lot d’accès. Je suis parvenu au constat que j’avais dans les 200 go de documents à migrer pour être certain de ne rien oublier. Cependant je perdais toute ma configuration, mais aussi ma vieille partition Windows en dual-bot que je gardais par acquis de conscience. Afin de sauvegarder tout ce petit monde je ne comptais pas réaliser une copie de dossier un à un, c’était un travail gigantesque mais également la meilleure solution pour oublier quelque chose. J’ai donc songé à un utilitaire présent dans toutes les distribs linux: dd. En gros celui-ci me permettait de copier l’intégralité de mon disque dur sur un autre support et cela sans me soucier des fichiers, des partitions, ni même de la MBR. Cela tombait bien: j’avais reçu quelques jours auparavant mon nouveau système de sauvegarde perso, un Lacie Quadra me permettant de faire des sauvegarde de 2 To en mirroring (RAID 1/0), ou de 4 To en mode fast. Paranoïaque avéré je l’ai bien entendu configuré en 1/0. Donc une fois le Lacie connecté en USB, je vérifiais ma table de montage (à peu près 200 fois, de peur de me retrouver une dizaine d’heure plus tard à rechercher des données après un mauvais format):

john@john-laptop:~$ mount | grep sda
john@john-laptop:~$ mount | grep sdb


Mon hd endommagé était bien sur /dev/sda et l’externe sur /dev/sdb. Même si cela peut paraitre stupide: quand on risque de perdre 200 go de données, on fait attention. J’ai donc ensuite bêtement executée:

dd if=/dev/sda of=/dev/sdb


Et j’ai laissé tourner pendant quelques heures. Et là j’ai noté quelques défauts dans ce cher et vieux dd. Tout d’abord par défaut la verbosité n’est pas exceptionnelle. On est dans le flou complet. Un mode interractif sans annonce de progression. Mais au bout d’une heure, j’ai pu avoir un peu de verbose; les choses ont commencé à mal tourner: il n’avait copié que 6,5 GO. Il bouclait sur une I/O error que générait sans doute l’un de mes premiers secteurs défectueux. Après un second essai du même acabit, j’ai RTFM pour de bon. Après un man dd, j’ai été réellement étonné de ne trouver aucun argument de type « onerrorskip » ou « noretry ». J’ai par dépit tenté un:

dd if=/dev/sda of=/dev/sdb conv=noerror,direct


Mais même en passant ces options il bouclait sur mes I/O error. J’ai laissé tourner pendant quelques heures supplémentaires pour ne copier au grand maximum que quelques dizaines de Mo de plus. Avant de me résoudre à entreprendre ce que j’avais réfuté du début (la copie de dossier un à un), je me suis penché du côté des livecds pour copier les données à partir de disques endommagés mais je n’ai pas vraiment trouvé de chaussure à mon pied. En revanche j’ai trouvé un fork de dd nommé ddrescue. Celui-ci ressemble à son grand frère à cette différence près: il ne boucle pas sur les erreurs, il les loggue et tente ensuite plusieurs passes pour récupérer les données potentiellement « perdues ». J’ai donc téléchargé le dernier en date, un configure,un make, et une doc plus tard, je lancais ca:

ddrescue -n /dev/sda /dev/sdb debug.log


Pour la petite histoire le -n évite de faire plusieurs passes sur la logfile afin de récupérer le maximum de données. Il s’oppose à -r qui est le max retries passes. Chaque secteur déféctueux est analysé une fois par passe. Comme j’étais pressé et que je voulais surtout tester si cela allait me sauver, je donc lancé avec -n. 30 heures plus tard ma copie était faite et surtout j’avais pu suivre le bon déroulement des opérations car ddrescue est très interractif:

Ce screen n’est pas celui de ma machine, il vous permet simplement de voir l’interactivité du soft. Au bout de 30 heures, il avait détecté 692 erreurs, estimé 67Mo d’errorsize, qu’il a su (en une seule et unique passe !) ramener à 6 mo. Je pense qu’en cinq passes je récupérais l’intégralité de mes données (je n’ai toujours pas trouvé ce que j’ai perdu, probablement de l’espace libre).

Après avoir vérifié en profondeur ma sauvegarde sur mon HD externe j’ai contacté Dell pour procéder au remplacement de mon disque dur. Comme d’habitude, SAV irréprochable, j’ai appelé vendredi soir, lundi matin l’un de leur techos l’un des techos de l’un des leurs sous-traitants pour le SAV était au bureau. Avant de rendre mon ancien disque dur j’ai bien pris soin d’effectuer deux opérations, un format bas niveau depuis l’utilitaire Samsung prévu à cet effet, ce qui a au passage résolu le soucis de secteurs déféctueux (temporairement, va sans dire), et suite à la résolution de ce problème de secteurs j’ai sorti mon plus joli:

dd if=/dev/zero of=/dev/sda


Idéalement j’aurai bien fait un

dd if=/dev/random of=/dev/sda


mais je n’avais pas la semaine devant moi. D’ailleurs chez Dell ils doivent avoir l’habitude des raleurs surtout lors de soucis de disque, ils m’ont échangé mon Samsung contre un Western Digital 500GO. Youhou 100 GO de gagné.

Pour conclure, je ne sais pas si cet article interessera beaucoup d’entre vous, il ne poursuit que quelques buts:

• Vous donner une méthode efficace de sauvegarde lorsque vous avez des secteurs défectueux. dd ne faisant pas son travail, ddrescue est votre ami. En effet vous avez bien mieux à faire lors d’un soucis hardware, surtout avec votre hd, que de penser à quels sont les fichiers à ne pas oublier. Autant prendre l’intégralité avec l’effort minimimum, cela tient en une commande.

• Vous donner une méthode vous permettant de récupérer vos données avec des secteurs déféctueux. Comme je l’ai dit, avec cinq passes je suppose que je retrouvais l’intégralité des mes données.

• Vous avertir sur le fait qu’au final Karmic Koala m’a sauvé, parce que ni mes outils de monitoring S.M.A.R.T sous windows (que je boot très rarement il est vrai), ni Jaunty ne m’avaient alerté. Il a fallu l’apparition de Palimpsest dans Karmic pour que je prenne conscience que mon disque dur était en train de mourrir en tentant désespérement de m’alerter.

• Que ce n’est au final pas si mal d’upgrader son système les jours de landrush: deux jours plus tard 300 secteurs disparaissaient à nouveau (juste à la fin de ma maltraitance sur /dev/sda avec ddrescue)

• Qu’il est préférable de rendre à son constructeur un disque dur où l’on a un peu compliqué la tâche des recovery tools: format bas niveau + /dev/zero ou /dev/random, même si ce n’est pas « parfait », je pense que c’est suffisant dans mon cas de figure.

• Qu’au final je n’ai pas fait le processus inverse:
  dd if=/dev/sdb of=/dev/sda pour restaurer mon système. J’ai réinstallé la dernière version d’ubuntu pour « profiter » de l’ext4 et avoir une réelle base de comparaison, et voir si ce FS est mal réputé à tort ou à raison pour son instabilité. Cela m’a permis de repenser ma gestion des lvms cryptés sur ma machine pour m’orienter vers une solution basée sur truecrypt, même si elle semble parfois mise à mal. Bon j’avoue, j’ai quand même copié mes /home/john/.* :)