Le premier enseignement est une confirmation de ce que tout le monde sait, ou devrait savoir, mais qu'une grosse majorité n'applique pas. La seule véritable parade à la perte de données reste la bonne vieille sauvegarde. Elle seule vous permettra de récupérer rapidement vos données et de restaurer votre système. Certes, vous allez perdre au pire quelques jours de travail, mais comparé avec ne plus rien avoir du tout, la question ne se pose pas. Donc, trois mots d'ordre à retenir : backup, backup et backup. L'argument généralement avancé pour justifier l'absence de backup est que ça demande du stockage additionnel qui coûte cher. Soit. Pour vous donner un ordre d'idée, cette récupération a coûté une vingtaine de fois le prix du disque perdu. Éloquent non ? Bref, si j'avais eu ne serait-ce qu'un backup de mon disque avant de m'envoler pour Cansecwest, je n'aurais eu à vivoter sur un système temporaire que pendant une semaine et j'aurais pu restaurer le système d'origine la semaine suivante. Et non trois mois plus tard...

J'ai récemment disserté sur la sauvegarde en ligne. Si je n'envisage pas cette solution pour la mise en place d'un vrai backup, elle s'avère utile comme solution additionnelle pour tenir à disposition certaines données bien particulières qu'on voudrait pouvoir récupérer très rapidement. On pensera à des clés privées, des keyrings et autres certificats, des stockages de mots de passe quand on en utilise, des fichiers de configuration spécifiques[1], quelques utilitaires à réinstaller rapidement. Bref tout ce qui va permettre de reprendre rapidement des activités normales. On pensera également aux emails, forcément. Et là, je ne cesserai probablement jamais de remercier IMAP qui m'a sauvé du désastre une fois encore. Ayant la chance de ne pas souffrir de quota sur mes boîtes personnelles, j'y conserve presque cinq années de correspondance[2], parfois plus... Au boulot, un quota relativement bas m'oblige à faire du stockage local, pour autant, le tampon que cela crée en ligne permet clairement de tenir la distance. Bref, mettre quelque part en ligne quelques informations[3] permet de continuer à bosser en attendant d'avoir accès à la sauvegarde. Comme le fait très justement remarquer Meik en commentaire, une clé USB fera également une bonne trousse de premiers secours, ayant l'avantage de ne pas nécessiter un accès à Internet.

Si vous n'avez toujours pas compris le message, je vais vous le répéter encore une fois : faites des sauvegardes. À côté d'une récupération, un deuxième disque dur ne coûte pas cher du tout pour faire un miroir de vos données. Et pour ceux qui confondent sauvegarde et RAID, sachez que sont deux choses différentes et l'un ne doit pas empêcher l'autre. Le RAID est une solution de disponibilité[4], la sauvegarde une solution de réponse à incident. En particulier, le RAID ne vous protège pas de l'effacement "involontaire" de données. Il se trouve d'ailleurs qu'une bonne partie du revenu des sociétés de récupération de données provient de grappes RAID, nettement plus fastidieuses, donc chères, à traiter. Comme quoi...


La prestation maintenant. Je me retrouve au final avec trois disques devant moi. Le cadavre, évidemment, qui m'a été sympathiquement retourné. À ses côtés, deux disques de 160Go chacun. Le premier contient le résultat standard de la prestation, c'est à dire mes fichiers. Sur le second se trouve une image complète de mon disque, opération pour laquelle j'ai dû batailler un peu. Le second enseignement, c'est que si vous faites appel à ce type de prestation, il faut être très clair sur ce que vous voulez. Ce que je voulais, c'était une image de chacune de mes huit partitions[5]. Pourquoi ? D'abord parce que l'une d'entre elle est chiffrée. J'ai donc besoin des données brutes ce qu'une récupération de fichiers ne peut pas me donner. Ensuite parce que j'ai envie de restaurer le système. J'ai donc besoin du contenu des fichiers, certes, mais aussi de leurs attributs. Je ne m'attendais pas à ce que ce genre de demande puisse être mal comprise ou poser un problème, bien au contraire, pensant qu'une simple copie bit-à-bit du support serait même plus simple à réaliser. Et bien non, ce n'est pas comme cela que ça se passe. Chez ce prestataire, récupération de données veut dire récupération de fichiers, et il a fallu quelques explications pour obtenir une image de mon disque en sus. Heureusement qu'avant toute opération, ils envoient un devis avec un bilan de ce qu'ils pourront récupérer, ce qui m'a permis de m'apercevoir que si nous parlions la même langue, le langage était manifestement différent.

J'ai donc ce disque USB, formatté en NTFS[6], contenant l'arborescence et le contenu des six partitions EXT3, chacune dans son répertoire. Manquent forcément la partition de swap et la partition chiffrée. À côté, un disque IDE de 3,5" contenant l'image complète du disque original, auquel je vais accèder avec un indispensable adaptateur IDE vers USB. Troisième leçon de valeur : trouvez-vous un adaptateur IDE vers USB, vous n'imaginez pas combien c'est pratique, surtout dans ce genre de cas. Après un survol rapide, c'est ce dernier qui va s'avérer utile, et pas le premier, qui vient de se voir attribuer le rôle de futur disque de sauvergarde.

L'image s'avère en effet totalement exploitable. La table des partitions est lisible, je peux toutes les monter, même la partition chiffrée se monte sans problème. Maintenant, il s'agit de procéder doucement et par étapes pour ne pas tout flinguer si près de la ligne d'arrivée. Je commence donc par faire un backup de chaque partition sur une machine en RAID, histoire de les conserver au frais. Au cas où. J'aimerais bien ensuite passer ce disque en lecture seule pour éviter toute manipulation malheureuse, mais ce n'est pas possible matériellement sur ce modèle. Je vais ruser en changeant les droits sur les devices associés lorsqu'ils sont créés par udev, avec dans le fichier permissions.rules quelque chose de ce genre :

KERNEL=="sda[0-9]*", MODE="0400"

Ensuite, chaque partition sera montée en lecture seule :

# mount -o ro /dev/sda1 /image/
# mount -o ro /dev/sda2 /image/usr/
[...]

Je branche maintenant le disque sur lequel je vais redescendre mes données, ce qui me donne cette magnifique pile de disques tous branchés en USB, et passe à son partitionnement.

Pile de disques USB

Je ne vais en effet pas faire directement une image, ayant décidé de modifier la taille de certaines partitions. En outre, comme je n'ai aucune garantie sur l'intégrité de l'image fournie, je préfère passer par une copie de plus haut niveau qui me permettra de voir les éventuels problèmes. De plus, le nouveau disque n'est pas identique à l'ancien et je ne voudrais pas que de sombres histoires de géométrie fassent tout capoter. Une fois le disque partitionné et chaque partition correctement formatée, je peux monter ma nouvelle arborescence :

# mount /dev/sdb1 /target/
# mount /dev/sdb2 /target/usr/
[...]

Il ne me reste à présent plus qu'à copier les données du répertoire image vers le répertoire target. Là, on trouve plusieurs écoles. Certains utilisent tar :

# cd /image
# tar cf - . | ( cd /target; tar xfp -)

D'autres que je suspecte de vouloir se la pêter pencheront pour cpio :

#cd /image
# find . -depth -print | cpio -pamVd /target

D'autres enfin optent pour l'économie de frappes et la simplicité en utilisant le bon vieux cp :

# cd /image
# cp -a * /target

Il se trouve que la copie se fait plus vite avec tar qu'avec cp. Personnellement, j'ai tout mon temps et une mauvaise expérience avec un tar buggé sur une Knoppix ; j'opte donc pour la dernière solution. Au passage, j'ai précisé la solution avec cpio parce que le tar de certains CD d'installation ne sait pas archiver. Une fois l'opération terminée, j'ai un disque qu'il ne reste plus qu'à booter. Enfin presque, vu qu'il n'a pas encore de MBR bootable. Pour le créer, je modifie légèrement le lilo.conf pour aller écrire sur /dev/sdb :

disk=/dev/sdb
    bios=0x80

On va ensuite réécrire le MBR:

# cd /target
# chroot .
# lilo

Il ne reste plus qu'à remonter physiquement le disque dans son logement et rebooter. Si ça ne passe pas, un coup de CD d'installation Debian en mode rescue devrait suffire à remettre les choses en ordre.

Et me voilà avec mon beau système tout beau tout propre. Il ne reste plus qu'à transférer les quelques données apparues depuis et ce sera fini. À ce sujet, pensez que pas mal d'applications, bien que sachant importer des données depuis d'autres applications, ne savent pas par contre importer des données d'un autre stockage de la même application. Par exemple, Evolution ne sait pas importer un autre stockage Evolution. Il faut lancer le client et exporter vos données locales, emails au format Mbox, calendrier au format iCal et contacts au format VCard pour pouvoir ensuite les importer dans votre installation courante. De même Mozilla ne semble pas capable de récupérer ses propres certificats. Il faut les exporter pour les réimporter ensuite... Ce qui veut dire que vous n'avez pas fini de travailler sur votre système temporaire, ne le tuez donc pas tout de suite, des besoins pourraient apparaître en cours de route, on ne pense clairement pas à tout, tout de suite.


Au final, ce que je retiens de l'expérience :

  • qu'il va falloir faire des backups, pleins, avec quelques données disponibles en ligne ;
  • que je ne sais pas encore ce que je vais utiliser pour cela, mais ça va venir ;
  • qu'un système temporaire se monte très rapidement et qu'on n'a pas besoin de grand chose pour survivre une ou deux semaines ;
  • que la récupération de données, c'est trop long et trop cher, et inversement.

Notes

[1] Genre le client VPN par exemple...

[2] Et c'est parce que j'en ai perdu deux suite à une manipulation malheureuse...

[3] Chiffrées, évidemment !

[4] Continuité de service par tolérance aux pannes, intégrité des données et performance.

[5] Oui, j'aime bien partitionner.

[6] Si quelqu'un peut me détailler les apports de NTFS par rapport à FAT32 dans ce cas là, je suis preneur.