Fsck et disque dur vide après!

Bonsoir,
J’ai un petit souci (en fait, non, c’est plutôt un gros).
J’ai mon pc portable qui n’a plus voulu démarrer ce soir. Avec des erreurs de type mdadm config not found, sauf que mdadm n’est pas utilisé sur la machine.
Après un peu de recherche, c’est un des disques qui n’est pas lu au boot.
J’ai donc démarré sur un livecd debian , et fait un fsck sur le disque.
Et la, le nombre d’erreurs a été phénoménal. Bon. Je fais malgré tout confiance et terminé le nettoyage, je monte le disque sur mnt: ah ben il est vide! Mais Lost+found lui est assez rempli .
Évidemment, c’est ma partition home qui est en vrac.

Auriez vous une idée si quelque chose est récupérable ? Ou si c’est simplement mort…
ddrescu peut il être mon ami ?

Merci de votre aide.

Rémi

Bonjour,

Ah, mince. En fait, lost+found, ce sont les objets trouvés. En gros, il a pu (peut-être) récupérer tous tes fichiers, mais il a totalement perdu l’arborescence des dossiers. Tu as donc tous les fichiers qui sont placé en vrac dans ce dossier lost+found pour que tu puisses, faute d’avoir leur nom, récupérer au moins leur contenu. D’après ce sujet, l’arborescence des dossiers semble perdue.

Attends un peu de voir si quelqu’un a une meilleure solution que cette que je te propose, à savoir, refaire l’arborescence à la main et restaurer tous les fichiers un par un, mais je ne pense pas qu’il y ait une autre solution.
Et pour ddrescu, je pense qu’il va être capable de récupérer tes fichiers non trouvés par fsck (ou que tu as supprimés), mais tu n’auras toujours pas l’arborescence.

Merci de ton avis.
Jeune comprends pas trop pourquoi le disque a défaillie de cette façon aussi soudainement.
Je vais tenter une première passe avec ddrescue on verra bien.
Tant pis pour l’arborescence. Ça c’est pas grave.
Une fois les données récupérées, de toute façon, je reformate et vérifie .
Je viendrai mettre les commandes effectuées et si ça a marché.

Rémi.

Non, tu vérifies avec l’outil smartctl ce qu’il en est de ton HD !
Parce qu’un FS ne « disparaît » pas tout seul comme ça sans aucune raison. Ca sent la défaillance disque dur. d’où smartctl !

Sinon, pour récupérer proprement les données, - si aucune sauvegarde ne sont faites ailleurs - c’est un outil comme testdisk !

Il vaut mieux le faire à partir d’une session exécutée depuis un autre OS, et analyse du disque pour recouvrer les possibles fichiers, sur un autre espace disque :wink:

Oui, j’ai répondu trop vite.
Bien sûr, smartctl sera mon ami.
Mais par contre je n’ai pas compris pourquoi je n’avais pas eu d’alerte avant.
Je m’en occuperai après. La c’est trop tard, faut avancer sur la récupération de données d’abord.

On fait souvent une confusion sur le rôle de fsck : il ne répare pas un système de fichiers, il le remet dans un état cohérent, au prix de la perte de données s’il ne peut pas faire autrement. C’est comme l’amputation d’un membre atteint par la gangrène : on ne soigne pas le membre, on élimine seulement le problème. Si les données sont plus importantes que la cohérence, il vaut mieux s’abstenir de passer fsck ou de faire quoi que ce soit susceptible de modifier le système de fichiers.

ddrescue, il aurait fallu le passer avant fsck pour qu’il soit utile.

Pas forcément, d’ailleurs le dernier message de cette discussion dit le contraire.
e2fsck met dans /lost+found les inodes « orphelins » qui ne sont référencés par aucune entrée de répertoire. Il peut y avoir principalement deux raisons :

  • il s’agit de fichiers qui ont été supprimés alors qu’ils étaient encore ouverts (technique courante pour créer et utiliser des fichiers temporaires qui seront automatiquement supprimés à la fermeture) mais qui n’ont pas été fermés correctement, typiquement si le système de fichiers n’a pas été démonté proprement. Ces fichiers peuvent être supprimés.
  • Il s’agit de fichiers dont les entrées de répertoire ont été perdues (corruption ou erreur de lecture de l’entrée de répertoire…).

Dans tous les cas, les noms originels des fichiers sont perdus car ils étaient stockés dans les entrées de répertoires. Par contre les autres méta-données (taille, attributs, propriétaire, permissions…) qui sont stockés dans l’inode et le contenu sont conservés.

A noter que lost+found peut aussi bien contenir des fichiers que des répertoires. Un répertoire n’est qu’un type de fichier particulier. Lorsqu’un inode orphelin est de type répertoire et sa structure cohérente, son nom est perdu mais les fichiers et sous-répertoires qu’il contient sont présents avec leurs noms originels.

Plutôt photorec qui est inclus dans le même paquet testdisk.

1 J'aime

@PascalHambourg @PengouinPdt
En tout état de cause, j’installe testdisk (avec un livecd)
Et en premier, je regarde la doc de testdisk et de photorec.

Ça permettra de refaire une c…