Perte de données : le pire des scénarii

ArticleCategory:

System Administration

AuthorImage:[Ein Bild von Dir]

[Photo of the Author]

TranslationInfo:

original in de Detlef Müller 

de to en Orla Shanaghy

en to fr Florent Morel

AboutTheAuthor:[A small biography about the author]

On m'appelle 'Linux' au Cyber Café, quand bien même cela ne fait que deux ans que je travaille avec le système d'exploitation de Tux... Peut être qu'il serait temps d'essayer un BSD maintenant...
Ce n'est pas un vrai travail pour le moment mais j'aimerais utiliser Linux dans ma vie professionnelle. Pour moi, Linux est donc à la fois un ersatz de travail et un hobby.
Depuis début 2004, mon autre hobby est Attac. J'ai envie de participer utilement au développement de Linux dans ce domaine.
Mon premier site...
L'idée : un système d'e-democratie qui permet à tous les participants de voter par Internet - en utilisant des logiciels libres, bien entendu.

Abstract:

Utiliser des systèmes de fichiers journalisés a été une des meilleures décisions que j'ai prises avec Linux. Le bien-fondé de cette décision a d'ailleurs été prouvé hier d'une manière très convaincante. Un procédé de copie vérolé a avalé toutes les données d'une partition, y compris l'ensemble des données d'un projet Linux, et a rendu la partition impossible à monter.
Ceci sur un système de fichiers ReiserFS...

Les systèmes de fichiers journalisés (noté jfs dans la suite de l'article) font partie de ces bonus qui sécurisent le travail sous Linux. Ils vous permettent de pouvoir utiliser la touche reset sans effet dévastateur - normalement (!) .
Ce rapport portant sur les pertes de données dans la vie de tous les jours montre que cela peut parfois avoir des conséquences très ennuyeuses et décrit le sauvetage héroïque des bits et octets par un outil Linux utilisé de manière professionnelle appelé 'reiserfsck'.

ArticleIllustration:[Das Titelbild des Artikels]

Mounted nicht

ArticleBody:[The main part of the article]

Introduction à Linux

Tux est installé sur mon ordinateur depuis près de deux ans - trois pingouins y cohabitent maintenant. Deux de l'espèce SuSE, un Debian, Knoppix pour être plus précis.

Tout a commencé avec SuSE 7.3, une affaire dégottée sur E-Bay. J'avais déjà beaucoup entendu parler de Linux et je voulais devenir moi-même un spécialiste de Linux, cela a donc été ma façon à moi de me lancer.

Les problèmes de débutants ...

Les premiers pas n'ont décidément pas été faciles. Combien de fois ai-je donné des noms d'oiseaux aux nouveaux termes techniques et particulièrement car ils ne sont (habituellement) jamais expliqués.
Quand vous lisez les premières phrases des manuels de la distribution allemande, vous êtes inondés de KDE, YaST, Bash, etc. ... et précédemment un magazine informatique renommé vous l'avait décrite comme la distribution la mieux documentée... Peine perdue - rien n'est clair ni simple.

Soupirs... mais ça passe. Revenons au sujet principal.

ReiserFS sur EISA 486

Ce SuSE Linux 7.3 a été installé sur un vieux 486 qui avait toujours un bus EISA (...oui, ces choses là existent encore). Le premier reset difficile (touche reset) suivi du redémarrage causèrent des problèmes. Plus d'accès au système de fichiers et un montage possible en lecture seule uniquement.
« Qu'est ce que cela peut bien signifier ? »
Cela signifie beaucoup de travail. Les tentatives de réparation ne portèrent pas leurs fruits... Finalement, j'ai tout simplement ré-installé complètement SuSE.
Ceci arriva 5 ou 6 fois. Chaque fois, je démarrais avec le système de récupération de SuSE, lançais l'utilitaire de réparation e2fsck pour les systèmes de fichiers ext2. Une fois, j'ai même édité le fichier /etc/fstab avec l'éditeur vi. Ensuite, le système de fichiers était réparé... ou bien non. Enfin, je réinstallais Linux. Cette étape effectuée, je venais d'y passer la journée. Ce genre de trucs prennent plus longtemps avec les débutants...

Puis j'ai eu l'idée - inspirée par un article sur c't (magazine d'informations techniques allemand) - d'installer un système de fichiers journalisé Yast. Aussitôt dit, aussitôt fait, et depuis, je n'ai pas relancé le système de récupération.
Si le PC n'a pas été correctement éteint, le message 'replayed nnn transactions in ...' (restauration des transactions nnn dans ...' apparait lorsque Linux est en train de démarrer, puis l'ordinateur démarre sans problème.
« Halleluia! » pensais-je. C'est mieux. À partir de maintenant, plus de ext2 - le « journalisé » est la voie à suivre !


'Journal replay' d'une partition ReiserFS pendant le démarrage... (depuis le fichier de logs) :



.....
reiserfs: found format "3.6" with standard journal
reiserfs: checking transaction log (sd(8,4)) for (sd(8,4))
reiserfs: replayed 109 transactions in 10 seconds
reiserfs: using ordered data mode
.....

Tests en charge

Cependant, je voulais m'assurer de l'efficacité de ces systèmes.
Une fois raisonnablement familier avec les jfs, je décidais de stresser un peu le système par le biais d'une série de tests. Le système de fichiers était sujet à des redémarrages intempestifs alors que des applications étaient lancées.

Ouvrir KDE, avec beaucoup de programmes, ouvrir des fichiers avec un éditeur puis cliquer sur le bouton Reset. Les tests furent probants. Le système de fichiers y survécu réellement.
Même activer la « sortie d'urgence » (emergency exit) pendant un processus de copie n'a pas posé de problèmes.
Le système SCI 486 posa quelques problèmes mais ReiserFS est à la hauteur de ce qui est annoncé sur le magazine. Il retourna toujours le système de fichiers à un état stable et cohérent. Les fichiers ouverts étaient revenus à leur état originel.
Les tests effectués plus tard dans les mêmes conditions avec ext3, la version journalisée de ext2, furent eux-aussi une réussite.

Voici le contenu du fichier de logs durant un démarrage du système avec ext3 :




.....
Journalled Block Device driver loaded
(recovery.c, 256): journal_recover: JBD: recovery, exit status 0,
recovered transactions 450798 to 451415
(recovery.c, 258): journal_recover: JBD: Replayed 3756 and revoked 6/15 blocks
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
ext3_orphan_cleanup: deleting unreferenced inode 355953
ext3_orphan_cleanup: deleting unreferenced inode 355952
EXT3-fs: sd(8,1): 2 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
.....

Les autres systèmes de fichiers journalisés

Ceci était le préambule...
Depuis, j'ai aussi testé ext3 et XFS.
J'ai laissé de côté JFS, puisqu'il est supposé non sécurisé pour l'instant. Je ne suis pas en train de dire quoi que ce soit de négatif à son propos, je ne l'ai simplement pas encore essayé.

XFS n'existe plus. Cela ne me dérange pas ; je n'avais pas eu le moindre problème avec mais je ne l'ai pas utilisé pendant bien longtemps.
Je continue à utiliser le système de fichier ext3. Il tourne maintenant sur le 486 avec une Debian / unstable.
Avec ext2, il est même possible de changer une partition existante en ext3 avec les données présentes sur la parttion. J'ai testé, ça marche !
J'ai encore utilisé ext3 la dernière fois que j'ai installé Knoppix version 3.4 sur mon disque dur.

La plupart des systèmes de fichiers sur mon PC de travail - un petit PIII/500 - sont actuellement ReiserFS.


Voici comment les deux disques de mon PC de travail sont partitionnés :

QtParted hda
Image 2, partitionnement de sda (disque SCSI)

QtParted hda
Image 3, partitionnement de hda

Le jour J

J'ai travaillé sur un CD de documentation pour Linux pendant les 3-4 dernières années. Cela implique un gros volume de données : howto, tutoriels, FAQ, plus différents formats et archives dans chaque cas, et le même volume encore pour les updates. Je suis aussi en train d'écrire des fichiers html pour qu'il soit aisé d'obtenir un aperçu du contenu du CD-ROM.
Il y a eu beaucoup à faire dans les semaines passées. Une version libre de ce CD doit être disponible bientôt. Donc - créer une image ISO, taper quelques commandes de gravure dans un script - est bien plus rapide que d'utiliser un programme KDE.
Puis je mets tout sur mon disque dur. Ma partition de stockage est /dev/hda5 sur un disque IDE de 60Go. La partition est de 20Go (dont 80% sont déjà remplis). Tous les bits et octets sont importants, impliquant beaucoup d'heures de travail. Si jamais quelque chose leur arrivait...oh et puis ce n'est pas près d'arriver, ce n'est pas Windows avec le système FATxx après tout.
J'ai souvent pensé aux sauvegardes (backups), mais je n'en ai jamais réalisé jusqu'ici. J'ai juste quelques copies sur un autre disque, et m'en tiens à ça.

Hier soir, je quittais le cyber-café doù j'avais téléchargé quelques paquets depuis le site web de SuSE. Il s'agissait de toute la documentation originale originale de SuSE 7.3 à 9.0 sur 2 cds. Une fois rentré, je démarrais mon PC avec SuSE 8.1. J'utilise d'habitude Debian, mais puisque les paquets étaient des RPMs de chez SuSE, j'utilisais la 8.1 cette fois. Et je pouvais installer les premiers paquets de la documentation de 9.0. Cela ne pose pas de problème particulier d'installer un nouveau paquet sur une version 8*. J'installais donc les paquets RPM 9.0, les copiais sur la partition hda5 pré-citée puis désinstallais les RPMs. Puis je fis de même avec une 8.0.

Sans fermer KDE, j'ouvrais une autre console et tapais <CTRL ALT> <DEL> pour arrêter le PC. Tout ce dont je me souviens est que j'obtins alors une erreur sur la ligne de commande - dont j'ai oublié le contenu. Je ne pouvais plus rien faire...
Très bien, je presse le bouton Reset - cela ne me fait plus peur de faire ça sur une machine Linux maintenant.

Le pire des scénarii

Quand je démarrais Debian, je ne m'aperçus de rien dans un premier temps. Puis au niveau de KDE : Aucun répertoire n'apparait sur ma partition de travail.
Elle n'a probablement pas été montée (non, n'importe quoi - elle est automatiquement montée au démarrage).

Puis après un 'mount /dev/hda5', le message d'erreur : 'too many file systems - or wrong superblock. L'affaire est en train de se corser...

Ce que je suis en train de vivre là est un cas réel du pire des scénarii de perte de données.

Et maintenant ? Hum... peut-être essayer de la monter à nouveau ? Inutile, si elle n'a pas pu être montée la première fois, cela ne risque pas de mieux marcher le seconde.
J'essayais quand même... nada ! La partition contenant le fruit de plusieurs mois de recherche, quantité de pages HTML écrites par mes soins, les scripts pour graver les cds, une collection de paquetages DEB et RPM récupérés depuis le Net, et beaucoup d'autres trucs - tout est parti, disparu, au Nirvana ou quelque part ailleurs.
Bien sûr, quelques données sont toujours sur le disque, mais pourrais-je y accéder à nouveau ?

Je me recule, allume une cigarette...
En tant qu'amateur de bricolage, la première chose qui me vint à l'esprit était la récupération des données. La partition est une ReiserFS. Des outils existent pour cela. J'ai lu une fois un article à ce propos sur Knoppix c't ; j'ai d'ailleurs installé Debian par Knoppix au début. Les outils devraient donc être là.
Et ils sont bien là.

reiserfsck en opération d'urgence

Donc : premièrement, regardez le répertoire des docs. Il doit se trouver dans /usr/share/doc/reiser-quelquechose. Dans Quelquechose (...ce doit être reiserfsprogs) j'ai trouvé quelques fichiers en anglais, un pour chaque outil, convertis depuis les pages de manuel (manpages).
Un rapide coup d'oeil sur les outils permettant la récupération de données révèle que reiserfsck doit être le 'scalpel'. Très bien, commençons maintenant...

Tout d'abord, je l'ai lancé sans changer quoi que ce soit. '-check' (vérification) semble être une bonne chose à faire dès le début. D'abord le diagnostic, puis l'opération...

# reiserfsck -check

Konsole Bild 1
Image 4, reiserfsck -check

Je n'y comprends rien, mais je comprends que reiserfsck a trouvé des erreurs et dit qu'il peut les réparer. Ça s'annonce bien.

J'y réfléchis une minute, puis lance l'opération. Appelée l'utilisation du scalpel...

# reiserfsck --rebuild tree /dev/hda5

Console graphic 2
Image 5, reiserfsck --rebuild-tree

Je suis nerveux. Pas étonnant - je suis sur le point de découvrir ce que je ferai dans les prochaines semaines.
« Should the file system be restored now? » (Le système de fichiers doit-il être restauré maintenant ?)... Oui, ça serait bien, merci.
J'obtiens le bon vieux message 'replaying journal'. C'est ce bon Samaritain qui rend possible la restauration - une sorte de table des matières de toutes les sous-partitions. Dans les deux lignes suivantes, reiserfsck rencontre un bit null erroné et... le corrige.

Vient ensuite la partie Pass 0 de la restauration, dans une nouvelle console. Cette étape prend 15 minutes pour mon 20Go... l'affichage du pourcentage réalisé permet à l'utilisateur de garder un oeil sur l'état d'avancement.

L'image 2 montre les détails d'une erreur. Qu'est-ce-que cela signifie exactement ? Hum... demandez-moi autre chose, vous voulez bien ? :)

Console graphic 3
Image 6, Pass 0 jusqu'à 2, 3 (début seulement)

Puis vient Pass 1, très rapide. Pas de message d'erreur.

Idem pour Pass 2.

Dans Pass 3, je suis inondé de messages d'erreur. Je reconnais ces fichiers, ils viennent du process de copie de la documentation SuSE. Ceci prouve que quelque chose a mal tourné lors de ce process de copie. Était-ce Konqueror ou un bug dans ReiserFS ?

Console graphic 4
Image 7, Pass 3 (fin)

D'après la description, une recherche de fichiers ou dossiers perdus est effectuée dans Pass 3a.

Console graphic 5
Image 8, Pass 3a

L'outil finit - normalement - par trouver ce qu'il cherche, spécifie l'erreur, puis corrige les entrées correspondantes, les commentant avec un 'corrected to...' à la fin de la ligne.
Puis il affiche le résumé de l'opération de restauration d'urgence. Dans Pass 4, il affiche un message annonçant que la synchronisation (du journal dans son état actuel sur le disque dur) est terminée.

Console graphic 6
Image 9, Pass 4 et fin

Maintenant, je devrais pouvoir accéder à mes données à nouveau.
Je n'obtiens pas de message pendant le mount - un signe sûr avec UNIX que la commande a été exécutée avec succès. :-))

Tout est bien qui finit bien ?

Konqueror affiche mes répertoires habituels sur la partition hda5. Tout est de retour... ou devrais-je dire, presque tout. Une partie des fichiers copiés est manquante - naturellement. Vous ne pouvez espérer un résultat parfait d'un process erroné. Je peux toujours les copier à nouveau.

Aujourd'hui, le jour suivant, je n'ai toujours pas vérifié toutes les données sur hda5. Mais il est fortement probable que tout a été complètement restauré. L'outil semble très professionel en usage intensif !

Il est maintenant 16:30, jour J+1. Le signal d'alarme a retenti il y a seulement 18 heures. Le rapport (celui-ci) est presque terminé - c'est dire si l'opération de restauration a été une réussite.
Je suis heureux d'avoir sauvegardé l'avancement de la console après la restauration dans un fichier hier. Cela signifie que je peux insérer des captures d'écran des incidents d'origine dans cet article.

P.S. (2 jours plus tard) : pas de trace de données perdues. Je travaille tous les jours sur la partition affectée.

Verdict

La perte de données peut aussi arriver sur un système de fichiers journalisé, cependant les chances d'une restauration complète sont plus élevées. Les jfs sont sûrs et faciles à maintenir.
Un jfs doit être employé par tout utilisateur Linux (vous pardonnerez cette forte prise de position dans le monde des logiciels libres).

La plupart des distributions proposent maintenant un jfs par défaut pendant la procédure d'installation.

Et... cela signifie pour ceux qui oublient de faire des backups qu'ils peuvent s'en passer.
Cependant, ceci n'est pas une incitation à ne pas faire de sauvegardes.
Donc, faites tout le temps des sauvegardes !

Références

Articles sur les systèmes de fichiers journalisés :

  • Journaling file systems for Linux - Linux Gazette numéro 68, Juillet 2001 ( de | en); .. avec beaucoup de détails.
  • Adventure ReiserFS - Linux Netmag 4/2000 ( de | en)
  • Doppelte Buchführung - Linux Magazine 1/2002 (de), comparaison de systèmes de fichiers journalisés (en allemand seulement).
  • Darf es etwas mehr sein ? - Linux Magazine 6/2000 (de), étendre ReiserFS à LVM (en allemand seulement).
  • Buchführung für die Festplatte - Linux Magazine 4/2000 (de), comparaison de systèmes de fichiers journalisés (en allemand seulement).
  • Crashfest - Linux Magazine 7/2001 (de) XFS sur SuSE 7.1 (en allemand seulement).


    • Sites web sur les systèmes de fichiers journalisés :

  • ReiserFS - page d'accueil de ReiserFS.
  • ext2 / ext3 - ou essayez cesite
  • XFS - Le système de fichiers journalisé de SGI.
  • JFS - ... Un projet Open Source IBM.


    • Articles concernant les backups :

  • RSync: le meilleur système de backup - LinuxFocus Mars 2004.
  • storeBackup, l'outil de backup non conventionnel - LinuxFocus Janvier 2004.
  • Arkeia, une solution commerciale, professionnelle pour les réseaux - LinuxFocus Mai 2000.