[Tuto] Bilan : comment récupérer des données perdues

xtriade · Le 28/04/2010, à 09:09

bonjour,
j'ai trouvé ce post sur le forum et j'aurai aussi besoin d'aide
je possede depuis un mois un disque dur sata de 1 To Western Digital Caviar green
je le branche habituellement dans un boitier externe en usb
tout marchait bien jusqu'à hier soir lorsque le disque a perdu sa table de partitions (je l'ai débranché un peu sauvagement au lieu d'eteindre le boitier par le bouton On/Off)

Avec la commande "fdisk -l" , le systeme le voit comme un disque de 2To , sans table de partitions
je suis en train de faire un testdisk dessus

peux t-on récupérer toutes les données en recréant une nouvelle table de partitions ?

Disk /dev/sda: 2199.0 GB, 2199023255552 bytes
255 heads, 63 sectors/track, 267349 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/sda doesn't contain a valid partition table

merci de votre aide

Nasman · Le 28/04/2010, à 09:29

Tu peux déjà commencer à afficher le contenu de ton mbr pour voir quel est le problème avec ta table de partitions

sudo dd if=/dev/sda bs=512 count=1 | hexdump -C

Ta table des partition est censée commencer en 0x1be

general alcazar · Le 28/04/2010, à 11:11

Il est formaté en quoi ?

xtriade · Le 28/04/2010, à 12:24

Nasman a écrit :

Tu peux déjà commencer à afficher le contenu de ton mbr pour voir quel est le problème avec ta table de partitions
sudo dd if=/dev/sda bs=512 count=1 | hexdump -C
Ta table des partition est censée commencer en 0x1be

Bonjour,
Le disque est formatté en ext3 .
Alors je donne le resultat de la commande :

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
1+0 enregistrements lus
1+0 enregistrements écrits
512 bytes (512 B) copied, 0,133595 s, 3,8 kB/s

merci

Nasman · Le 28/04/2010, à 12:27

Effectivement, tu n'as plus rien dans ton mbr, ni partie exécutable, ni table des partitions, ni signe de média bootable (octets 55 et aa en fin de secteur 0x1fe et 0x1ff

xtriade · Le 28/04/2010, à 12:28

et c'est mort ou récupérable avec testdisk ?

rmy · Le 28/04/2010, à 23:06

A mon avis, la géométrie du disque étant fausse, dd ne peut rien lire de satisfaisant ici. Peux-tu nous dire ce que testdisk te donne comme géométrie ?

Peux-tu aussi ouvrir un autre post spécifique à ton problème, et mettre le lien ici ? Je ne manquerai pas d'en faire le bilan une fois qu'on en saura plus. C'est pour ne pas trop encombrer la lecture sur mon post, et te donner aussi plus de chances d'aide efficace, grâce à une plus grande visibilité.

xtriade · Le 28/04/2010, à 23:31

bonjour,
voici le lien sur un autre post : http://forum.ubuntu-fr.org/viewtopic.php?id=392005

Pour l'instant testdisk est en train d'analyser le disque, c'est tres tres lent (27%), j'ai lancé le test ce matin vers 10h

Géométrie :
CHS : 267349 255 63

Mon disque est un 1To , testdisk trouve 2To !

Merci

Dernière modification par xtriade (Le 28/04/2010, à 23:36)

chown6471 · Le 01/05/2010, à 19:48

Bonjour cher disk-gourus!

Voilà, le sujet de mon post est simple: AU SECCCOOOUUURRRSSS!!!!!

(un peu d'humour ne fait pas de mal quand on est désespéré!!)

Tout d'abord, félicitations pour ce très bon topic riche en enseignements...

Je viens humblement vous exposer ma situation avec tous les détails nécessaires à une bonne compréhension... Mon post est long, mais je crois qu'il ne s'agit pas d'un cas d'école, il couvre en fait un éventail assez vaste de sujets liés aux problèmes disques, et qu'il devrait théoriquement trouver sa place dans ce topic déjà bien garni-i-i!!!

Je promets donc de m'exprimer dans un bon français pour que l'exposé de la situation puisse si possible servir à d'autre

Linuxiens... en y ajoutant un peu d'humour si possible pour rendre l'exposé moins rébarbatif...

Je compte enfin sur votre expertise (merci rmy, Skippy, et autres bonnes âmes) pour me dire ce que vous en pensez...

N'hésitez pas à me remonter le moral, je plaisante pour me rassurer, mais je vis très mal la perte de mon travail....

D'abord, et pour que vous puissiez comprendre ce film d'horreur en un clin d'oeil, voici un résumé de la situation actuelle, à l'heure où je poste ce message:

En résumé:

Je ne parviens pas à remonter sous Ubuntu 9.10 un système de fichiers RAID-0 (pourtant diagnostiqué sain) composé de 4 disques de 470 Go qui étaient originellement installés dans mon NAS de Thecus N4100. Le log système indique l'erreur principale suivante:

EXT2-FS Group Descriptors corrupted

(Note perso: Mouaifff... quand on a dit ça, on a tout dit, et on a rien dit... ça ressemble à une foultitude d'autres posts sur des sujets RAID... lisez la suite tout de même...)

Intermède:

Les détails qui suivent (nécessaires) sont longs. Si vous souhaitez une synthèse, allez au paragraphe final "Synthèse"; vous pourrez éventuellement revenir aux détails si mon cas vous interpelle....

Premières impressions / A savoir:

(1) Vous pensez peut-être qu'il s'agit d'un problème RAID et que cela ne concerne pas ce topic... Toutefois, j'ai procédé assez méthodiquement à des analyses, tests, j'ai écumé les forums sur le RAID, et comme vous le verrez ci-dessous, je crois que le problème à traiter se réduit en fait à un (simple?) problème de récupération d'un système de fichiers.

Toutefois, étant donnée la foule d'hypothèses, je manque de connaissances, et je ne trouve pas d'infos suffisamment détaillées sur mon cas spécifique pour résoudre ce problème...

(2) Je ne suis pas un "super super" expert système Linux / Disques, mais suffisamment informé pour réussir à me dépatouiller d'un assez grand nombre de situations. Suffisamment expérimenté aussi pour savoir que quand on croit savoir, il convient en fait de rester humble, de ne pas hésiter à demander conseil, et qu'en l'espèce, et malgré mes efforts pour rester rationnel et prudent, il est possible que j'ai commis quelques erreurs dûes à des instants de panique dans la résolution de ce problème... Dans la suite de cet historique, je vous ferai part de mes "erreurs"; néanmoins, ayant tenté d'agir avec prudence, ces erreurs (sauf peut-être une) ne devraient pas théoriquement avoir de réelle conséquence fâcheuse.

A vous de juger...

(3) Techniquement, vous pouvez de façon certaine considérer comme garanties les hypothèses de travail suivantes:

(a) Le NAS Thecus N4100 n'est absolument pas défaillant: j'ai acheté cet appareil il y a 4 ou 5 ans; il marche parfaitement (encore maintenant). Je n'ai pas d'actions chez Thécus, mais pour faire court: voià bien le seul et le meilleur investissement informatique que j'ai fait ces dernières années... Increvable cet appareil... Jusqu'à ce que l'erreur HUMAINE (mais oui... moi-même en l'occurrence!!) qui a déclenché ce cauchemar ne se produise, je disposais d'un NAS composé de 4 disques identiques de 470 Go/disque, montés en RAID-0 (peut-être pas le meilleur choix de RAID, mais il y a 4 ou 5 ans, cet équipement était cher et j'avais besoin de d'espace disque), soit une capacité totale d'env. 1.6 To.

Sur le RAID, j'ai stocké des données essentielles pour différents travaux, dont notamment deux projets (en cours) que je souhaite offrir à la communauté open-source, soit environ 18 mois de travail.... disparus.

Ceci vous fixe donc l'enjeu: ces données sont essentielles, et je suis prêt à tout pour les récupérer... Mon intuition c'est que cela est possible car les données sont là, j'en suis certain (voir historique ci-dessous).

NOTE:

SVP, ne me dites pas: as-tu fait un back-up de tes projets+données? En fait, techniquement, il est nécessaire que le projet s'exécute à partir du NAS, et les données ( par exemple, des images d'OS, ou une grande quantité de contenus multimédia) font partie intégrante du projet comme données de tests... impossible donc de backuper de telles quantités de données à moins de m'équiper d'un second disque de même capacité... En un mot comme en mille, j'ai considéré (avec raison) que le NAS est mon équipement le plus sûr pour le stockage de mes données. Et vu le nombre de pannes rencontrées sur d'autres matériels (laptops et autres ordis...) ces dernières années, et vu le fait que le NAS tourne comme une horloge 24/7, à même le sol en compagnie de quelques "moutons" (de passage)... bref, autant dire que cet équipement est fiable, et qu'il était raisonnable de le considérer comme un medium de stockage fiable, en attendant de pouvoir m'offrir une solution de stockage plus récente et moins onéreuse. Ce n'est donc pas une erreur matérielle, mais bien une erreur humaine dans un contexte de projet où un back-up était financièrement hors de ma portée...

En clair: si j'avais pu le faire, j'aurais évidemment backupé mes données de test, mais je n'ai pas les moyens de m'offrir deux fois le même équipement... ai-je clarifié toute ambiguïté?.... :-). Je me sens déjà assez mal comme ça....

(b) Les 4 disques RAID sont en parfait état physique (au moins une bonne nouvelle!). Aucune défaillance mécanique et/ou électronique à noter, car elle permet quand même d'orienter des solutions...

Maintenant l'historique détaillé des évènements:

Historique:

(1) Jour 0, Round 0, courant février 2010

Je travaille sur un projet (open-source) qui prévoit de proposer une solution clés en main de serveur de distribution / installation d'OS Linux / Windows en réseau. Le projet est basé sur la spec PXE, normalisation d'une structure de répertoires installable sur tout disque accessible en réseau via TFTP. Le projet inclut aussi (et c'est le module le plus important) un atelier de création, configuration d'images Windows customisables. Un très gros morceau de programmation, essentiellement basé sur un framework extensible écrit en DOS Batching... Un cauchemar de programmation quand on est habitué aux joies du Bash. Lors d'un test, une variable mal réglée, et Patatras: à l'issue de son exécution le script principal (qui lance l'exécution de la génération d'une image Windows XP et son déploiement dans le serveur PXE, soit env. 40 minutes d'exécution) efface le script principal lui-même.... AAArrrgggghhh!!! Le cauchemar vient de commencer, mais à cet instant, celles/ceux d'entre vous qui programment régulièrement et ont déjà connu ce type d'instant, vous savez qu'il s'écoule généralement env. une minute pendant laquelle votre cerveau est subitement traversé par une sorte de... vide...

Oui, je programme depuis plus de 25 ans, et cette situation, je ne l'ai connue que 3 fois. Donc, je ne suis évidemment pas parfait dans l'art de la prudence, mais raisonnablement, je crois que 3 fois en 25 ans, ça va... que celui qui programme depuis aussi longtemps et qui n'a JAMAIS connu cela me jette la première pierre...

Ah, et puis au fait, puisqu'on en parle... et bien oui, justement, j'avais un back-up du script principal daté de la veille, mais hélas inexploitable en l'état vu le très grand nombre de changements effectués dans l'intervalle de temps, et impossible de repartir en codage de ce script backupé. Il fallait absolument récupérer le script dans son état courant....

(2) Jour 0, Round 1: Récupération du script effacé sur le NAS

Après le vide intersidéral qui vient de traverser mon cerveau quand je constate que mon script n'est plus là, suivi du hurlement bestial intérieur "Ché pas possible!!!", je reprends mes esprits et me résouds à traiter (euh... calmement?) le problème: récupérer le script.

Problème: un NAS (en tout cas, chez Thécus), c'est plutôt le genre: boîte noire.... donc, la question est comment récupérer ce fichier alors qu'aucune fonction undelete n'est disponible sur le NAS.

Après quelques recherches sur le net, je découvre que PhotRec est THE outil (merci Christophe Grenier) qu'il me faut absolument essayer pour récupérer mon script. Je dois donc installer PhotoRec sur le NAS, l'exécuter avec un bon paramétrage, croiser les doigts, et on verra bien...

Heureusement, Thécus a eu la bonne idée d'upgrader le firmware du N4100. Je n'avais pas voulu tenter l'expérience de l'upgrade, car après tout, l'upgrade ne corrigeait pas réellement le fonctionnement initial du NAS (pour moi très correct), mais apportait plutôt des nouveautés, dont une, en fait assez sympathique: la possibilité d'ajouter des plug-ins fonctionnels au NAS, et notamment, une fonctionnalité media-center...

- J'upgrade le Firmware et grand bonheur, ej dispose maintenant d'un plug-in dont j'avais VRAIMENT besoin: le plug-in SSH.

- J'installe le plug-in SSH, je me connecte en mode console sur le Thecus, ça marche... YESSSS!!! L'autre bonne nouvelle, c'est que de nombreux utilisateurs Thécus rapportent qu'il est possible d'installer des programmes supplémentaires dans le firmware du Thecus... Alors on y va....

- Le firmware du Thecus N4100 est un système Linux basé sur Debian, et compilé semble-t-il pour une architecture processeur ARM.

- Comme je ne parviens pas à trouver PhotoRec pré-compilé pour cette architecture processeur j'entreprends de le cross-compiler si possible en statique. (Je passe les détails...). PhotoRec se compile en dynamique, mais le make échoue en statique.

- Impossible d'exécuter PhotoRec en librairie dynamique sur le Thécus. De mémoire: il manque des librairies et/ou les librairies du Thécus ne sont pas au bon niveau ou tout simplement incompatibles...

- Conclusion: il faut absolument compiler PhotoRec en statique, mais je ne trouve pas dans le makefile ce qui provoque le problème qui fait échouer le linkage. Désespéré (et très inquiet) en fin de journée, je me résouds à prendre contact avec Christophe Grenier (auteur de PhotoRec, merci Christophe!!), qui me répond avec beaucoup de gentillesse quelques jours plus tard.

(3) Jour 0, Round 1 ERREUR 1:

- ERREUR: être passé à l'action immédiatement.

L'aide que m'a fourni Christophe m'aurait sans doute permis d'éviter ce qui suit ci-dessous. Je pourrais m'auto-flageller 1000 ans en me répétant qu'il eût été plus prudent de rester sur la stratégie initiale: récupérer mon script en installant et en exécutant PhotoRec sur le NAS. Cela est sans doute vrai. Mais sur l'instant, le facteur humain, la fatigue, ont été les plus forts.

- DECISION (très mauvaise): je prends la décision d'extraire les 4 disques durs du NAS, je cours acheter des boîtiers USB, afin de remonter le RAID sous un Linux plus conventionnel (Ubuntu), et exécuter PhotoRec sur le RAID ainsi remonté.

NOTE: avant de prendre cette décision, je parcours quelques forums qui semblent indiquer que cela est possible, et que l'outil mdadm est l'outil de prédilection pour cela.

(4) Jours 1 + 10zaine de jours suivants, Round 2: remontage du RAID impossible...

- Mes 4 disques durs sont dans des boîtiers externes USB. Chaque disque a été numéroté dans son ordre d'emplacement initial dans le NAS, afin d'éliminer toute suspicion relative à l'ordre des disques lors de leurs assemblage (les forums RAID indiquent que l'ordre des disques importe).

- Beaucoup de documentation + forums parcourus sur le RAID et en particulier sur l'outil mdadm et son fonctionnement.

(a) ERREUR 2: vitesse et précipitation

[NOTE: je passse les détails de ligne de commande sur mdadm, car ils ne sont pas (sauf erreur de ma part) au centre du problème]

- Pensant agir d'une façon prudente je branche le premier des 4 disques et je lance la commande d'assemblage RAID mdadm sur ce disque. mdadm me gronde en indiquant que le RAID ne peut pas être assemblé.

- Explication: évidemment, idiot que je suis: en RAID-0, chaque fichier est découpé, et chaque morceau dispatché sur un disque du RAID. Pour reconstituer un système de fichier RAID-0, il est donc nécessaire d'assembler en une seule fois TOUS les disques, faute de quoi, le RAID, il va forcément marcher moins bien.... ou pas du tout.

- Cette erreur toutefois, ne devrait pas avoir de conséquences: je ne pratique aucun diagnostic en écriture sur le disque 1 du raid, par conséquent, il est intact.

(b) ERREUR 3: et si on continuait à faire des bêtises???....

- Bon, à ce stade du récit, vous vous dites: "A y est!! Il est parti en sucette... Qu'est-ce qu'il va encore faire?"

- Réponse: une erreur.

- Pourquoi? Après l'échec d'assemblage du RAID en (a), j'ai un doute qui m'assaille: et si j'avais involontairement endommagé mon ensemble RAID en tentant de le monter dans un autre contexte que celui du NAS?

- Pris dans ce doute, je veux vérifier que mes 4 disques peuvent toujours se réassembler sans problème dans le NAS. Je prends donc mes 4 disques, je les replace dans l'ordre initial dans le Thecus, je relance le NAS, et là, horreur: le NAS mouline un certain temps au boot, entre deux et cinq minutes (inhabituel), puis m'affiche que mon RAID n'est pas configuré. Plus aucune donnée visible sur les disques....

- Question: que s'est-il passé dans le NAS? Ne me dites pas qu'il a effacé mes données, ou bien la table des partitions, ou pire: reformaté les 4 disques..... Le formatage de 1.6 TB prendrait de toute façon plus de temps que 5 minutes, et un simple file check avec auto-correction certainement plus de temps aussi...

- Confirmation? Aucune confirmation, ni aucune information obtenue sur le net concernant ce que le NAS a fait lors de ce boot. Là où çà pêche chez Thécus, c'est vraiment au niveau des informations très techniques sur leurs produits, enfin, en tout cas pour des produits un peu anciens comme le N4100.

Peut-être le NAS n'a-t-il rien fait à part un file check, et s'est juste contenté de m'indiquer qu'il y a un problème qui l'empêche de retrouver ses données, et qu'il considère donc que le RAID n'est pas configuré. De plus, je ne parviens pas à trouver une trace de cela dans les logs du Thecus. Donc, ce qui est très problématique, c'est que je ne peux en rester qu'aux stade des hypothèses.

Si vous avez des explications ou autres hypothèses à formuler, n'hésitez pas, même si c'est pour me faire part d'une mauvaise nouvelle (cela m'évitera au moins de me fourvoyer):

Hypothèses:

* Niveau de risque sur cette erreur: ELEVE, car je ne sais pas ce qu'a fait le NAS.

* Risque lié à un file check effectué par le NAS: impossible de dire si le NAS a vraiment effectué un file check, pourquoi il l'aurait fait, et s'il l'a vraiment fait, a-t-il tenté une réparation automatique qui aurait éliminé les données, et tout cela en l'espace de deux à cinq minutes qu'a duré le boot. Pour moi, ce type d'opération aurait pris plus longtemps, donc très improbable.

* Risque de perte des données: MOYEN/FAIBLE: il est quand même peu probable que le NAS reformatte des disques sans rien dire, quand il ne détecte pas un système RAID configuré. Et encore une fois, s'il devait reformater, il reformaterait probablement les 1.6 TB, soit plus de 5 min de boot nécessaires avant d'être disponible.

* Risque d'effacement de la table de partitions: POSSIBLE. Cela traine dans certains forums concernant les NAS, avec une réinitialisation de la table de partitions quand le RAID n'est pas initialisé correctement.

La question de fond, la question principale:

J'allais oublier la question qui précède les autres:

* Pourquoi le NAS ne peut-il plus subitement réassembler 4 disques que j'ai seulement tenté de remonter sous Linux, en prenant soin de ne rien écrire dessus?

Suite des évènements:

- Ni une ni deux, j'éteinds proprement le NAS, je remets les disques dans leurs boitiers USB, les reconnecte à Ubuntu car je sais qu'à partir de maintenant:

* Je ne suis plus en face d'un problème de récupération de fichiers, mais

* En face d'un problème de récupération d'un système de fichiers,

* Il m'est devenu impossible de retrouver mes données dans le NAS,

* Il va falloir trouver une solution qui passera par un remontage du RAID + récupération du système de fichiers EN DEHORS du NAS.

Points négatifs:

- J'ignore si j'ai perdu mes données en remettant mes disques dans le NAS

Points positifs:

- N'ayant (a priori) exécuté AUCUNE opération de lecture / écriture sur le NAS après le boot, il n'y a (encore a priori) pas de raison logique (sauf si c'est le mode de fonctionnement du Thécus par défaut), pour que les données et/ou les partitions aient été effacées.

- Un autre argument (mais j'anticipe un peu sur les résultats d'assemblage RAID effectués aux étapes suivantes): l'erreur que je vais rencontrer aux étapes suivantes est une erreur fréquemment rencontrée par des utilisateurs RAID lors de l'assemblage de leur RAID sous Linux avec l'outil mdadm. Et dans un grand nombre de cas, l'erreur est le symptôme de causes multiples. Evidemment, il serait faux de tenter de me rassurer et de me convaincre bêtement qu'il y a forcément une explication autre que la perte de données, mais la réalité des cas rencontrés semble indiquer que tant que des disques n'ont pas de problèmes physiques et/ou mécaniques, tant qu'on parvient à réassembler un RAID sain, en général, il y a souvent une chance non négligeable pour que les données soient toujours là, mais inaccessibles en raison d'un problème de paramétrage ou de table de partition effacée. Alors pourquoi serai-je l'exception à cette note d'espoir???

(c) PROBLEME RAID: assemblage RAID incohérent

- Lors de mes essais suivants, j'ai compris la grossiereté de mon erreur commise en (a) (il était temps!), et j'assemble maintenant sous Ubuntu mes 4 disques connectés dans leur ordre de numérotation avec mdadm.

- Malheureusement dans cette phase d'essais qui dure plusieurs jours, je suis confronté à un problème de Superblocks.

- Et là, je suis un peu perdu. lors de la création/assemblage mdadm m'indique qu'il ne trouve pas de superblock permettant de réaliser un assemblage correct des disques.

Donc, l'assemblage RAID via mdadm ou bien échoue, ou bien je me retrouve avec un assemblage RAID incomplet et incohérent...

De plus dans la documentation et les forums traitant ext2/ext3, il est également fait mention des blocs et super-blocks...

- Parle-t-on de la même chose en fait?

- Après quelques jours de galère sur les forums et sur la documentation ext2/ext3/raid, j'arrive à comprendre (enfin grossièrement) que d'un côté, la structure-même de ext2 prévoie la notion de noeuds pour le stockage et l'organisation physique des données, les superblocks sont également utilisés, entre autres, pour la table de partition du disque.

- Sur la documentation RAID, les superblocks sont également mentionnés, mais leur utilisation, sauf erreur de ma part, serait destinée à contenir des méta-informations permettant de réaliser un lien logique entre plusieurs disques physiques et/ou partitions qui seront ensuite assemblable ensemble. La littérature sur mdadm mentionne également l'UUID du disque RAID assemblé, qui doit être inscrit et identique sur chacun des 4 disques. Je comprends que grosso modo les superblocks RAID devraient donc (entre autres) contenir l'information d'identification d'un disque dans un contexte d'assemblage RAID, où le disque RAID final assemblé aura le même UUID que chacun de ses membres...

- Ces éléments assez théoriques sont, de mon point de vue, confirmés sur des forums où l'on indique que dans ce type de situation, il suffirait (conditionnel) de regénérer les superblock RAID sur les disques pour être en mesure de les assembler correctement.

- Sans rentrer dans les détails: j'utilise les options de commandes de mdadm pour regénérer les superblocks raid.

NOTE IMPORTANTE:
Durant toutes mes manipulations, cette opération en écriture sur les disques est la seule que j'ai volontairement effectuée.

- J'exécute:

sudo blkid

- J'obtiens 4 disques avec le status "linux raid member" pour chacun, et avec des UUID identiques. Parfait!

- Après moults essais, je tente de réassembler l'ensemble RAID via mdadm sur /dev/md0:

sudo mdadm -A /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3

mdadm: /dev/md0 has been started with 4 drives.

Ca marche!!!

NOTE:
Ca marche, mais quand même... je suis un peu perturbé par mdadm. Pas par le dernier essai ci-dessus qui a réussi, mais lors

de de plusieurs essais précédents avec la commande d'assemblage. J'avais essayé différentes combinaisons de switches, et notamment, j'avais du essayer un truc comme:

sudo mdadm --assemble --scan

Au lieu d'assembler explicitement les devices et de préciser leur ordre d'assemblage, je laissais mdadm scanner les devices et assembler les device détectés. Lors de ces essais donc, mdadm analysait et assemblait les 4 disques un par un et pour la phase d'assemblage, il renvoyait dans la console les infos suivantes (je ne me souviens plus exactement des messages exacts, mais il s'agissait de quelque chose comme):

* disque 1: seems to contain an ext2fs partition
* disque 2: (rien de special)
* disque 3: (rien de special)
* disque 4: (rien de special)

Avec le dernier essai: mdadm -A /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3, je n'obtiens plus ces messages. Toujours est-il que cela me perturbe car le disque 1 semble être vu différemment des 3 autres disques.

Hypothèses 1 et 2: quelqu'un sait-il?

Cela me perturbe car, si on admet que les 4 disques d'un RAID0 doivent être exactement partitionnés de façon identique, alors on pourrait s'attendre à ce que les 4 disques, et non pas un seul, disposent effectivement d'une partition ext2fs... Ou bien, autre hypothèse sur laquelle je n'ai pas trouvé de réponses: le disque 1 d'un RAID-0 contient peut-être seule les informations de partitionnement, tandis que les autres disques n'ont pas besoin de cette information déjà contenue dans le disque 1 qui serait alors un disque "maître" pour un RAID-0...?

Ce que j'écris a-t-il du sens pour vous? A moins que vous ne disposiez de connaissances sûres en RAID-0 qui pourraient lever ces questions, au moins peut-on admettre qu'il est logique de se poser ces questions...

Hypothèse 3: après tout, pourquoi pas...

Enfin, il y a la troisième hypothèse qui me vient à l'esprit tandis que je vois ces messages: et si la ré-écriture des superblocks RAID via mdadm avait tout simplement effacé les informations de partition sur les disques 2, 3 et 4...

Hypothèse 4: et après, ils diront que je suis totalement fou!!!

Ben, tant qu'on y est, pourquoi ne pas s'interroger sur le partitionnement d'un RAID-0. J'ai eu beau chercher des informations sur le Net, je n'ai rien trouvé de spécial à ce sujet. Le RAID-0 est moins bien documenté que les autres RAID.

Mais ce qu'il ressort de ce que j'ai lu, c'est qu'a priori, il est difficile de prédire de quelle façon un RAID sera partitionné, le partitionnement (ou pas) pouvant dans certains cas (cartes contrôleur RAID, NAS?) résulter d'un processus propriétaire. Là, on retombe d'ailleurs sur les questions concernant le NAS et ce qu'il a "bricolé" pendant son boot à l'étape (b) ci-dessus.

Dans mon cas, il est certain qu'aucune carte contrôleur RAID n'est intégrée dans le NAS. Il s'agit bien RAID software. Reste à savoir si le Thécus N4100 réalise effectivement le partitionnement de ses disques RAID. Si la réponse est non, d'où provient donc cette partition ext2 présente sur le disque 1, tandis que les disques 2, 3, et 4 n'en possèdent pas?

Comme vous le voyez, ce n'est pas faute d'essayer de raisonner, mais je manque de connaissances théoriques sur ce sujet....

- Je referme cette parenthèse, car au final, la commande d'assemblage mdadm semble s'être terminée pour la première fois sans échouer.

Hein? Quoi? Serait-il possible que.... oui.... serait-il possible que j'ai réussi malgré tout????

(A genoux devant le clavier, transpirant et tremblant): "ÔÔÔÔÔ toa, seigneur Oubountou, donne-moi la force... oui, donne-moi la force de taper encore quelques commandes sur ce clavier..."

- Puis un coup de:

cat /proc/mdadm

arrosé d'un coup de:

sudo mdadm -D /dev/md0

me renvoient tout tranquilou l'information qu'un ensemble RAID /dev/md0 est présent, assemblé, sain et est constitué de 4 disques chacun dans un état "active sync", soit un ensemble RAID de 1.6 TB.

"Merci à toi, Ouboouuuuuntou!!!"

(J'ai regroupé à partir de l'étape (10) les messages renvoyés par ces commandes).

- Là, à environ Jour 0 + 10 ou environ, je commence enfin à respirer. Naturellement, je suis loin de me douter que les problèmes ne sont pas terminés.... Enfin quand je dis "je suis loin de me douter...", j'exagère un peu, en fait: avec quelques années d'informatique dans les pattes, le "pif" a tendance à se développer un peu, même chez les plus optimistes d'entre nous, si bien que dès qu'on obtient un succès dans la résolution d'un problème, on a généralement acquis le réflexe conditionné qui consiste à éviter de se réjouir trop vite en faisant la danse sioux autour de l'ordi... Non, en fait, avec le pif un peu développé, on a plutôt tendance à se dire simplement et calmement: c'est déjà ça....

- Car il reste l'épreuve finale: remonter le système de fichiers RAID.

- "RRROOââaaahhhh, l'autre...." allez-vous me dire en rigolant... "Trop facile, fingueurz in ze noze". Oui, en fait, c'est exactement ce que je me suis dit en reprenant mon souffle après la danse sioux.

- Allez, un coup de:

sudo mount /dev/md0 /home/moi/mon_raid_adoré

Et voilou!!! Mount renvoie:

mount : type erroné de syst .de fichiers, option erronée, super bloc
        erroné sur /dev/md0, codepage ou aide manquante ou autre erreur
        Dans quelques cas certaines informations sont utiles dans syslog - essayez
        dmesg | tail  ou quelque chose du genre

Ah ben oui mais non!! Ce n'est pas vraiment ce que j'attendais!!

D'autres problèmes en perspective... donc!

- Redocumentation sur le net, forums, etc.

(5) Intermède:

Après presque 3 semaines en Février intensives passées sur cette situation qui se dégrade de plus en plus (par ma faute), enfin, une situation dont je ne vois pas le bout du tunnel, je décide de faire une pause d'une semaine ou deux pour les raisons suivantes:

(a) Je suis au bout de toutes les solutions que je pensais pouvoir mettre en oeuvre, et je suis réellement abattu, c'est rare...

(b) Raisons professionnelles

(c) Un principe de précaution (à la mode?): se documenter, encore, encore avant d'entreprendre une quelconque action

(d) A la fin de l'étape (4), je découvre que je vais peut-être devoir entreprendre des actions de corrections en écriture sur les disques. Quelque soit l'action à entreprendre, il est hors de question d'effectuer une quelconque opération sur les disques d'origine: il va falloir travailler sur des images disques.

(6) Mars 2010, Round 3

- J'ai remonté un peu la pente moralement, et me sens prêt pour un nouvelle quête de mes données... Bon, on ne parle même plus de récupérer mon script Batch DOS ce serait la cerise sur le gâteau... si le journal du FS n'est pas récupérable il y aura bien peu d'espoir. Enfin, on pourra toujours espérer encore avec PhotoRec si je récupère d'abord le système de fichiers intact....

- J'ai fait l'acquisition d'un Fujitsu StorageBird 2 To USB acheté chez mon Auch... favori afin de stocker les 4 images disques que je vais créer et sur lesquelles je vais travailler.

- Autant vous le dire tout de suite: si je cite la marque et modèle du disque dur, c'est que je vous déconseille FORTEMENT l'achat de cette M#&de. Un boitier Fujitsu, un disque dur Hitachi. Bref, vous allez voir que comme si les problèmes existants n'étaient déjà pas suffisants avec l'énergie que l'on dépense à trouver des solutions pour les résoudre, on va en rajouter une couche dont on n'a vraiment pas besoin afin de satisfaire la sacro-sainte Loi de Murphy.

- Stratégie de base: créer 4 images disques brutes sur le disque dur 2To

- Faisable? Ben voui.

  dd if=/dev/disque1 of=/dev/storagebird/disque1.dd

et ainsi de suite pour les 3 autres disques.

- C'est parti.

- Euh... non. Attendez!! J'ai oublié de préciser. Comme j'avais vraiment la patate, je me suis autorisé un peu d'optimisme:

* Achat d'un Hub USB 6 port avec alimentation externe optionnelle
* Branchement des 4 disques RAID en USB sur le Hub
* Le StorageBird branché directement sur le second port USB de l'ordi
* Afin d'éviter tout problème de mise en veille des disques: désactivation des fonctions de gestion de l'énergie au niveau des disques

Bref, j'ai tout prévu!!! Ah!! Ah!!! Plus rien ne m'arrêtera!!!

Un peu de calcul théorique. Débit max USB: env. 30 Mo/s. Mon RAID est rempli à 80% de la capacité théorique max des disques (480 GB) soit environ 4 x 375 = 1500 GB. Bon, c'est un calcul à la louche, évidemment. Avec le débit en lecture d'environ 30 MB/s, il faudra environ 15 heures pour créer les 4 images...

Alors vous allez dire: "on s'en moque...". Ah ben oui mais non. Je mentionne ce point pour que quelque chose soit clair à l'esprit de celle ou celui qui en passe par là: si vous décidez de travailler sur des images disque, soyez conscient qu'une fois que vous aurez tenté une ou des actions correctives de quelque nature que ce soit sur vos images, et dans le cas malheureux où elles n'ont pas abouti, et bien:

* Vos images disque sont consommées, inutilisables, et bonnes pour la poubelle

* Il faut recréer les images du ou des disques puis recommencer d'autres action correctives.

Tout cela pour dire et je répète ce que dit parfaitement rmy: être patient, mais surtout, sélectionner le mieux possible QUELLE(S) action(s) corrective(s) sera(ont) à effectuer.

A ce titre, et je referme la parenthèse, je me permets d'ajouter dans ce topic un point qui ne m'a pas semblé être mis en avant dans les posts de conseil (ou peut-être ne les ai-je pas lu). Si vous exécutez des actions de diagnostics sur un disque original, essayez toujours des les effectuer en mode lecture seule (même si l'action perd de son efficacité).

Par exemple, sur les disques originaux de mon raid, je me suis TOUJOURS limité à des commandes de type: efsck -n /dev/un_disque afin de garantir qu'aucune modification involontaire n'était effectuée sur un disques traité.

Cette remarque permet aussi de comprendre pourquoi le scope des actions que l'on peut effectuer sur des disques physiques d'origine est en fait assez limité. Très vite, si l'on veut réellement voir ce que produisent vraiment des commandes de réparation telles que e2fsck (ou testdisk), il devient évident qu'il va falloir travailler avec des images des disques afin de se garantir un risque 0.

- Parenthèse refermée.

- Essai 1: Vers 23 heures, je lance mes 4 dd simultanément sur mon Hub USB et pars faire un gros dodo (en fait, pour être tout à fait honnête, j'ai utilisé l'outil ddrescue qui offre de meilleures garanties contre les erreurs éventuelles).

Au matin, 7 env. 7 heures de copie, ça roule, je ne touche pas à la machine, je bricole à côté. Au bout d'environ 10 heures, mes 4 images sont (presque) présentes sur le storagebird avec presque 300 Go de stockés pour chaque image. Vers 10 heures et quelques minutes, le storagebird attend traitreusement que j'ai le dos tourné pour une pause "petit coin", et quand je reviens: PPPPOOiiimmppp!! Erreur d'écriture sur le disque, des messages pas clairs, et tout le tremblement....

Euh... comment dire? Je suis à cet instant traversé par une vague envie de me saisir de ce nouveau disque dur et de lui coller une baffe, mais je me ravise finalement: il paraît que ça ne sert à rien.

Plus sérieusement: examen des logs système. A l'évidence, le Hub fonctionne bien. Chaque disque USB à lire a fonctionné correctement. En revanche, côté StorageBird, le port USB indique une mise en veille inexplicable du port, avec les insultes habituelles d'erreurs I/O qui vont avec.

Résultat: Faute à pas de chance? Erreur reproductible? Chais pas. Trop tôt pour dire. Je recommence.

- Essai 2: on respire un bon coup et on y retourne....

Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 6 heures de copie. Une journée de travail ch#énte foutue.

- Essai 3: très vénère...

Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 1 heure de copie.

- Essai 4: très très très vénère...

Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 10 minutes de copie.

- Essai 5: si çà plante encore, je m'inscris à l'épreuve du lancer de disques aux prochain J.O, et je promets que j'amènerai mon propre équipement....

Machine éteinte pendant une heure, puis rallumée. Partition Storagebird reformatée, clean. Même plantage après env. 2 heures de copie.

- Bilan: entre chaque essai documentation sur les forums. Je passe sur la réputation discutable et discutée des disques Hitachi, sur les (trop) habituels problèmes rencontrés sous Linux ou Mer#~oze avec des disques USB qui se mettent en veille, est-ce le disque lui-même, est-ce le PCB qui est complètement foireux (soit-dit en passant ce serait la seule contribution réelle de Fujitsu dans ce produit) ?

Bref, j'ai tout lu. Gros abattement: non seulement je ne peux toujours pas récupérer mes données, mais en dépit de tous mes efforts (j'allais oublier qu'à partir de l'essai 3, j'ai acheté deux multiprises sophistiquées avec fusible intégré, la peau des fesses... et que chaque multiprise n'alimente que deux disques durs USB tandis que chaque multiprise est branchée dans une prise murale distincte... bref, je vous laisse imaginer le plat de spaghettis de câbles d'alimentation USB, cordons USB, hub USB, etc.).

Tout çà pour çà....

(7) Intermède:

- Je décide de retourner encore une fois sur les forums et à la pêche à la documentation.

- Pendant ce temps, je suis tellement agacé, qu'encore une fois, je décide de faire une pause de quelques jours afin de garder les idées claires. Heureusement mes obligations professionnelles m'auront au moins permis de me faire oublier ce problèmes pendant quelques semaines.

(8) Avril 2010, Round 4:

- Ca y est! J'ai la pêêêêche!!! Je suis un Ouineur!! Ca va pulser !!!

- J'avais carrément envisagé d'acheter un nouveau NAS (tant pis pour le prix) avec 4 ou 8 To pour y copier mes images disques, car avec un bon NAS, au moins, pas de problème de mise en veille intempestive. Mais j'ai abandonné cette idée. Trop cher mon fils, et puis un peu de bon sens: j'ai déjà perdu des données, acheté un DD de TB (plus de 180 EUROS); il va falloir faire avec ce qu'on a....

- RV avec le SAV de Auch... Effectivement, le problème semble connu, et pas seulement sur les 2 To, mais depuis les Storagebird 1 To. La question: est-ce que c'est le DD qui part en vrille, ou bien est-ce le PCB???

- Réponse de Auch...: y savent pas, mais les techniciens s'y connaissent un peu, et en plus (coup de bol), l'un d'eux est Linuxien, et il me conseille de démonter proprement le boitier et de brancherle DD 2To directement dans une machine... Si ça marche pas, je remonte le boitier, et eux renvoient au constructeur en exigeant un changement du matériel...

- Mouais... mouais... mouais.... :-/ cette idée, je l'avais déjà eue avant d'aller les voir. Je crois que j'aurais pu moi-même conclure que j'avais acheté une grosse m#~douille.... Mais ouvrir ma machine de bureau qui est un cauchemar dès qu'on modifie un branchement (un XPC Shuttle SN25P), retirer un disque pour faire mumuse avec un autre disque... Pfff... quel cirque....

Sans compter le fait qu'il y a un détail croustillant à propos des Fujitsu storagebird que vous serez heureux de connaître: les modèles StorageBird 1 To disposent de vis pour démonter le boîtier. Bizarrement, les modèles 2 To ont des boîtiers qui s'emboitent avec des clips plastique dans la masse du boîtier. En clair, si tu veux ouvrir ton StorageBird 2To, il faudra casser le boîtier à coups de tournevis, à moins d'être le champion du monde du démontage.... Moi, perso, je suis patient, mais vu l'assemblage du boîtier, j'ai vite compris qu'il m'était impossible de le démonter sans le casser.

Je suppose, et n'y voyez au pire que du mauvais esprit de ma part, que Fujitsu aura pris soin de mettre tout son génie dans le packaging de leur M#&-de plutôt que dans la qualité des composants et/ou de la conception du produit. Ils devaient peut-être en avoir assez d'être submergés de retour constructeur de leur daube qui "dort tout le temps". Moi, j'ai pas eu le choix: à l'heure où je poste, c'est le seul DD 2To que j'ai pu trouver en rayon, et manque de bol, il était vendu dans un boîtier...

Oui, oui, vous allez dire: "mais peut-être que c'était seulement un défaut sur le modèle que tu as acheté...". C'est vrai, et c'est pourquoi je me taxe de mauvais esprit par sécurité. Mais vu le feedback officieux des techniciens Auch.. sur les modèles 1To et qui semblent confirmer mon problème, et vu le nombre de messages concernant ces modèles sur différents forums, j'ai tendance à croire que vous mettre en garde contre ce modèle de disque dur est un service que je rends à votre porte-monnaie.

Et dire que je m'étais promis de ne pas acheter de disque dur pacakagé en boîtiers USB mais d'acheter de simple boîtiers sans électronique additionnelle...

- Première action: je fais une nouvelle tentative de création d'image. Cette fois-ci, j'effectuerai tout le processus sur ma machine de bureau (le Shuttle), plutôt que sur mon laptop (essais précédents): machine plus puissante, risque réduits concernant des problèmes éventuels d'alimentation, et surtout, cette fois-ci, je vire le Hub USB (bien que je suis persuadé qu'il n'est pas en cause), et je créerai 1 image à la fois. Pour cet essai, le disque Fujitsu est TOUJOURS dans son boîtier d'origine et branché port USB de la machine. Le disque dur RAID source est lui aussi dans un boîtier USB relié au second port USB de la machine...

C'est parti. Au bout d'env. 4 heures, plantage :-) Mêmes logs, mêmes erreurs, le disque dur Fujitsu est parti en sucette et s'est "endormi" pendant la copie.

- Deuxième action: prendre une décision. Si je renvoie le disque en SAV, plusieurs semaines d'attente... peut-être un nouveau disque dur StorageBird avec le même problème...

- Je prends le risque. Démontage (cassage sauvage du boîtier, ça défoule!!!), branchement du disque nu dans le XPC shuttle, et hop! en 10 minutes chrono, mon XPC Ubuntu 9.10 reboote et reconnaît le disque. Impeccable!! Au moins une chose à laquelle je peux me fier: le système d'exploitation !!!

- Je relance la création d'une image avec le premier disque dur RAID branché dans son boîtier externe USB. Débit 30 MB/s, soit entre 4 et 5 heures pour la création de l'image, si tout se passe bien.

- 4 heures et des poussières plus tard: ddrescue vient de me créer avec succès une image disque disk1.dd de 372.4 Go.... Finalement, mon estimation sur la taille finale des images n'était pas trop mauvaise. J'avais initialement estimé la taille à 375 Go...

- Conclusion 1: YOUPIIIIIIII!!!!!

- Conclusion 2: Plus sérieusement:

* Le disque dur Hitachi n'est (a priori) pas en cause. C'est le système de branchement/alim du boîtier du Storagebird qui est complètement foireux. Donc, vous savez maintenant ce que vous faites si vous achetez ce modèle....

* Comme initialement prévu et calculé, j'ai pu créer les 4 images des mes disques durs sur le disque 2 To.

* Je vais passer à l'assemblage des images en RAID dans l'étape suivante:

(9) Montage des images RAID members, Round 4, fin:

- Là pas de grosse surprise, mais tout de même, un petit test implicit. En général on peut se fier à l'image créée par ddrescue. Donc, si je pouvais assembler mes 4 disques physiques en RAID auparavant, j'espère que je pourrai obtenir (au moins) un assemblage de leurs images avec le même succès.

- Les étapes habituelles:

losetup /dev/loop0 /media/storage_bird/disk0.dd
  losetup /dev/loop1 /media/storage_bird/disk1.dd
  losetup /dev/loop2 /media/storage_bird/disk2.dd
  losetup /dev/loop3 /media/storage_bird/disk3.dd

- Youplà! Ca marche... Mes 4 fichiers images disk0.dd, disk1.dd, disk2.dd, disk3.dd sont respectivement les loop devices /dev/loop0, /dev/loop1, /dev/loop2, et /dev/loop3.

- Maintenant j'assemble mes disques avec mdadm. Bon il y a plusieurs façon de le faire: j'utilise ici le switch -A pour l'assemblage, vu que chaque image disque est supposée avoir déjà été assemblée précédemment au sein du même array RAID et que par conséquent, les 4 images doivent avoir le même UUID.

  sudo mdadm -A /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3

me renvoie:

mdadm: /dev/md0 has been started with 4 drives.

- Résultat: YEEEEEEEEESSSSSSSSS! Ca marche.

- Un coup de:

  cat /proc/mdstat

me renvoie les infos suivantes:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 

md0 : active raid0 loop0[0] loop3[3] loop2[2] loop1[1]
      1562061056 blocks 64k chunks

- Et enfin arrosé par:

  sudo mdadm -D /dev/md0

qui me renvoie les détails suivants sur le RAID /dev/md0 assemblé:

/dev/md0:
        Version : 00.90
  Creation Time : Fri Feb 19 01:23:02 2010
     Raid Level : raid0
     Array Size : 1562061056 (1489.70 GiB 1599.55 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Fri Feb 19 01:23:02 2010
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 64K

           UUID : ecfe8404:2f354a45:d66856da:8e136666
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1
       2       7        2        2      active sync   /dev/loop2
       3       7        3        3      active sync   /dev/loop3

- Conclusion: mon raid sur/dev/md0 est bien assemblé, sain, en RAID 0, et constitué de 4 disques dans l'état "active sync".

- Rempli d'un espoir totalement irrationnel, j'essaie de monter le système de fichiers bien que je sais déjà qu'en toute logique, cela ne pourra pas fonctionner. On sait jamais, avec un coup de chance.... Mais euh... non. Même motif, même punition que précédemment. La commande:

sudo mount /dev/md0 /home/moi/mon_raid_adoré

me renvoie comme je le craignais:

mount : type erroné de syst .de fichiers, option erronée, super bloc
        erroné sur /dev/md0, codepage ou aide manquante ou autre erreur
        Dans quelques cas certaines informations sont utiles dans syslog - essayez
        dmesg | tail  ou quelque chose du genre

- Conclusion: bon, ben voilà. J'ai mes 4 images disques, je sais réassembler mon RAID, le système de fichiers ne se monte toujours pas. C'est normal.

- Faisons un coup de: fdisk -l pour voir comment est vu le disque /dev/md0. La commande me renvoie:

Disque /dev/md0: 1599.6 Go, 1599550521344 octets
2 têtes, 4 secteurs/piste, 390515264 cylindres
Unités = cylindres de 8 * 512 = 4096 octets
Identifiant de disque : 0x00000000

Le disque /dev/md0 ne contient pas une table de partition valide

- Ben voyons..... pas de table de partition... cha alors!!!

- Terminons maintenant par l'examen de messages.log pour voir ce qui s'est passé dans les coulisses pour l'assemblage du

RAID, et la tentative ratée de montage du système de fichier. J'imprime ici seulement la section de messages.log qui semble importante:

0000 May  1 17:30:17 obelix kernel: [  482.249802] md: bind<loop1>
0001 May  1 17:30:17 obelix kernel: [  482.249802] md: bind<loop2>
0002 May  1 17:30:17 obelix kernel: [  482.249859] md: bind<loop3>
0003 May  1 17:30:17 obelix kernel: [  482.249911] md: bind<loop0>
0004 May  1 17:30:17 obelix kernel: [  482.268841] raid0: looking at loop0
0005 May  1 17:30:17 obelix kernel: [  482.268849] raid0:   comparing loop0(781030528)
0006 May  1 17:30:17 obelix kernel: [  482.268854]  with loop0(781030528)
0007 May  1 17:30:17 obelix kernel: [  482.268858] raid0:   END
0008 May  1 17:30:17 obelix kernel: [  482.268861] raid0:   ==> UNIQUE
0009 May  1 17:30:17 obelix kernel: [  482.268864] raid0: 1 zones
0010 May  1 17:30:17 obelix kernel: [  482.268868] raid0: looking at loop3
0011 May  1 17:30:17 obelix kernel: [  482.268872] raid0:   comparing loop3(781030528)
0012 May  1 17:30:17 obelix kernel: [  482.268877]  with loop0(781030528)
0013 May  1 17:30:17 obelix kernel: [  482.268880] raid0:   EQUAL
0014 May  1 17:30:17 obelix kernel: [  482.268883] raid0: looking at loop2
0015 May  1 17:30:17 obelix kernel: [  482.268888] raid0:   comparing loop2(781030528)
0016 May  1 17:30:17 obelix kernel: [  482.268892]  with loop0(781030528)
0017 May  1 17:30:17 obelix kernel: [  482.268895] raid0:   EQUAL
0018 May  1 17:30:17 obelix kernel: [  482.268898] raid0: looking at loop1
0019 May  1 17:30:17 obelix kernel: [  482.268902] raid0:   comparing loop1(781030528)
0020 May  1 17:30:17 obelix kernel: [  482.268906]  with loop0(781030528)
0021 May  1 17:30:17 obelix kernel: [  482.268909] raid0:   EQUAL
0022 May  1 17:30:17 obelix kernel: [  482.268912] raid0: FINAL 1 zones
0023 May  1 17:30:17 obelix kernel: [  482.268921] raid0: done.
0024 May  1 17:30:17 obelix kernel: [  482.268925] raid0 : md_size is 3124122112 sectors.
0025 May  1 17:30:17 obelix kernel: [  482.268930] ******* md0 configuration *********
0026 May  1 17:30:17 obelix kernel: [  482.268934] zone0=[loop0/loop1/loop2/loop3/]
0027 May  1 17:30:17 obelix kernel: [  482.268945]         zone offset=0kb device offset=0kb size=1562061056kb
0028 May  1 17:30:17 obelix kernel: [  482.268949] **********************************
0029 May  1 17:30:17 obelix kernel: [  482.268951] 
0030 May  1 17:30:17 obelix kernel: [  482.268979] md0: detected capacity change from 0 to 1599550521344
0031 May  1 17:30:17 obelix kernel: [  482.273463]  md0: unknown partition table
0032 May  1 17:31:05 obelix kernel: [  530.560739] EXT2-fs: group descriptors corrupted!

- Conclusion: intéressant.

* Lignes 0000-0003: lors de l'assemblage, mdadm fait en dernier le binding de /dev/loop0 (le premier disque raid physique), alors que pourtant je l'assemble explicitement comme premier device de l'ensemble RAID. Etrange? Ou bien pas important? Bref

* Lignes 0004-0023: je suppose que l'algorithme de mdadm compare les identifiants des disques 2, 3 et 4 avec celui du disque 1 (/dev/loop0) et/ou vérifie que les tailles des disques sont identiques. Cette phase, je suppose encore, doit permettre à mdadm de savoir que ces 4 disques sont logiquement assemblés ensemble...

* Lignes 0026-0027: est-ce que ces infos sont correctes? Comment vérifier leur cohérence de façon sûre? Intéressant de constater que l'ordre affiché des devices semble correct avec /dev/loop0 comme premier device. Cela pourrait venir confirmer que le premier disque d'un assemblage RAID-0 est considéré d'une façon un peu spéciale par rapport aux autres disques...

* Lignes 0029-0030: une fois assemblé, la taille du RAID est bien la sommes des tailles des 4 disques: a priori normal, mais qui indique donc aussi que les informations sur le remplissage du disque sont quand même lisibles... un bon signe, non?

* Lignes 0031-0032: ça, c'est ce qui se produit lors du mount. Donc, en gros, ce qu'il faut comprendre c'est que les descripteurs de groupe EXT2 sont nazes... Cela suffit-il à expliquer l'absence d'une table de partition???

Beaucoup d'utilisateurs RAID ont fait un constat similaire en utilisant mdadm avec des descripteurs de groupes a priori nazes, mêmes sur des disques en assemblage RAID qui n'ont subi aucune modification par rapport à l'instant t-1 où ces mêmes disques fonctionnaient encore parfaitement...

Donc, à ce stade, ma situation ressemble exactement à celle des autres. Il y a néanmoins une différence avec les autres utilisateurs qui ont reporté ce type de problème. Dans la plupart des cas, la solution qu'on leur a proposée sur des forums fonctionnaient, car la solution proposée étaient adaptée à leur RAID, le plus souvent de type RAID-5, solutions qui s'appuient sur un réassemblage partiel des disques afin de forcer une ré-écriture des superblocs RAID, et je ne sais quoi encore...

Malheuresement, aucune solution même inspirée de ces solution n'est applicable à mon cas de RAID-0, car TOUS les disques sont nécessaires simultanément. C'est la raison pour laquelle j'avais forcé la regénération des superblocs RAID, ce qui, jusqu'à présent à au moins permis de garantir le lien logique d'assemblage entre les 4 disques.

Malheureusement, aucune solution en vue pour la reconstruction de la table de partition.

- Alors quelle différence avec "AVANT" les images disques?

Simple: maintenant, je vais pouvoir effectuer les opérations correctives (écriture) que je me suis interdit de faire jusqu'à présent. Si je me plante: 15 heures pour recréer les images, réassemblage RAID, et je repars sur une autre stratégie corrective. Ce sera long, mais il suffit seulement de patience, les disques durs physiques, eux, sont au chaud. Ils ne craignent rien...

(10) Round 5: actions en écriture...

- C'est parti...

- Je commence par exécuter ce que j'ai rêvé de faire pendant plusieurs mois: lancer e2fsck non plus en simple diagnostic, mais laisser l'outil faire les réparations si possible manuellement afin de limiter les actions au strict minimum.

(a) Petit diagnostic de base: sudo e2fsck -n /dev/md0

e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Les descripteurs de groupe semblent en mauvais état... tentons d'utiliser les blocs de sauvetage...
le superbloc a un journal invalide (i-noeud 8).
Effacer ? non

e2fsck: Illegal inode number lors de la vérification du journal ext3 pour /dev/md0

- Conclusion: ce diagnostic semble cohérent avec les autres problèmes reportés ci-dessus.

Ce qui est intéressant, c'est que ce que rapport indique que mon RAID sera formaté en EXT3 puisqu'il cherche un journal. Je me trompe ou pas? Si je ne me trompe pas, et si je parviens à récupérer mon système de fichier intact (que de si...), alors il reste un espoir que je puisse récupérer mon script effacé...??

(b) Tentative de réparation manuelle: infaisable...

- Commande

e2fsck -p /dev/md0

- Ca ne va pas: la commande me demande de modifier noeud après noeud manuellement. Il y en a pour des années, car le nombre de noeuds à réparer se compte en millions!!!.... Si je réponds non rien n'est modifié, et toutes les 3 questions, e2fsck m'informe que si je réponds oui, il y a un risque de destruction important des données. Bref: situation Cornélienne...

- Mon intuition: si autant de noeuds sont à réparer, c'est que la seule façon de réparer le système de fichier doit passer par une autre solution que e2fsck. Par exemple, testdisk ou autre utilitaire. Mais ce qui doit être entrepris dans la suite, fait partie de l'aide concrête que je vous demande....

(c) Tentative de réparation automatique:

- En début de semaine je lance la commande:

fsck -y /dev/md0

- Je lance cette commande car je veux en avoir le coeur net: je veux laisser e2fsck faire ce qu'il veut au moins une fois en automatique. Mais je me doute qu'en répondant "oui" automatiquement, il y a bien peu de chances pour qu'il en sorte quelque chose de correct. Après tout, un peu de bon sens: le fond du fond c'est que le système ne voit pas de table de partition. Comment e2fsck pourrait-il réparer des noeuds correctement s'il ne sait pas à quoi ces noeuds correspondent... C'est clair pour vous? Bon, moi, j'me comprends en tout cas...

- Résultat: e2fsck a tourné toute la nuit. 100% de CPU utilisé. Un truc de fou. Le disque dur 2To a chanté. Au petit matin, l'opération est terminée avec une suite infinie de logs de réparation / suppression de noeuds... bref.... impossible de reproduire toute ou partie de ce logs.

- Fébrillement (et sans grande illusion) je tape:

sudo mount /dev/md0 /home/moije/raid

- Ca plante encore, avec un message d'erreur que j'ai oublié de noter (désolé). Ce que je sais, c'est que le message n'était plus le message d'erreur mount habituel. Ce qui m'a incité à relancer la correction e2fsck pour une seconde passe...

- Donc, je tape une deuxième fois:

fsck -y /dev/md0

- Là, e2fsck tourne à nouveau, pendant une durée assez courte, peut-être une demi-heure, une heure max.

- e2fsck me rend la main. Je retente un mount. Ca marche!!!

- Je tape frénétiquement:

cd /home/moije/raid

,

suivi d'un pauvre

ls

- Et là: rien, que dalle, vide, niente, nada, nichts, peau'd'zobe... rien donc, à part le dossier /Lost+Found rempli d'un nombre gigantesque de dossier dont les noms sont numéros. Je suppose qu'il doit s'agir des noeuds réparés et qui ont été détectés puis réalloués comme des dossiers.

- A tout hasard je tape:

ls -R

afin de voir si certains de ces dossiers contiendraient ne serait-ce que quelques fichiers.

- Résultat: rien, que dalle, nada, etc... Tous les dossiers sont vides comme on pouvait le craindre après une telle opération de réparation en deux passes.

- Conclusion: e2fsck a bien essayé de réparer quelque chose, le seul problème, c'est juste que e2fsck ne comprend pas du tout ce qu'il répare!!!

- Conclusion de conclusion: mouais.... comme je l'ai dit, fallait tenter le coup. C'est fait. Maintenant, il faut passer à autre chose.

(d) Les étapes suivantes: à venir ? Help wanted!!!

- Me reste-t-il un espoir? J'ai bien quelques idées sur ce qu'il faudrait utiliser mais là je touche au fond de ce que je crois maîtriser et j'ai donc besoin d'aide...

** PISTE 1:

Une première piste serait d'exploiter une réparation en utilisant les superblocks de remplacement. Mais sont-ils seulement disponibles? Afin de préparer le terrain, j'ai lancé une simulation de création de système de fichier EXT3 avec la commande

mkfs -n /dev/md0.

J'obtiens:

mke2fs 1.41.9 (22-Aug-2009)
Etiquette de systeme de fichiers=
Type de systeme d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
97632256 i-noeuds, 390515264 blocs
19525763 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=0
11918 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
Superblocs de secours stockés sur les blocs : 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

Et à partir de là? J'ai effectivement une liste de superblocs de secours. Je sais qu'il y a un calcul bête comme chou (une multiplication je crois, numéro du superbloc x taille d'un block en Ko?) à effectuer pour indiquer l'offset d'un superbloc de secours, mais vraiment, cela m'aiderait beaucoup si quelqu'un pouvait me porter assistance sur cette piste.... Si ça rate, pas de regrets ni d'angoisse: je vous rappelle qu'il s'agit seulement d'images disques... On peut les regénérer en 15 heures ;-)

** PISTE 2:

- Je suppose que mon dernier recours sera l'outil testdisk. Mais quand (si) on doit envisager cette piste, je suppose que là encore, une âme charitable me prêtera assistance.

(11) SYNTHESE DE LA SITUATION:

- 4 disques durs de 470 Go montés en RAID-0 dans un NAS Thecus N4100, soit une capacité exploitable d'env 1.6 To

- Disques extraits du Thécus pour effectuer la récupération d'un fichier effacé par erreur (avec PhotoRec), en les remontant sous Linux.

- Impossible de remonter les disques en RAID sous Linux.

- Après de nombreux essais, le RAID peut être réassemblé avec succès, mais le système de fichier ne peut pas être remonté.

- Les deux diagnostics qui remontent sont:

* Le disque /dev/md0 n'a pas de table de partition valide

* Dans messages.log: le système EXT2 a des descripteurs de groupe corrompus.

- Impossible également de remonter les disques dans leur NAS d'origine.

- Stratégie: création de 4 images disques montées en loopback, puis assemblage RAID des 4 images afin d'effectuer des corrections en écriture sur ces disques.

- La correction e2fsck n'a rien donné.

- J'envisage la piste de réparation de la table de partition à l'aide des superblocs de secours. Mais j'ai besoin d'aide pour cette solution

- Si la solution précédente ne fonctionne pas, j'envisage la piste testdisk en dernier recours. Mais là aussi, j'aurai besoin de votre aide...

- Evidemment, toute autre solution / analyse et/ou diagnostic de votre part est bienvenu(e)...

Merci de votre aide précieuse.

rmy · Le 02/05/2010, à 01:57

Pfiou, sacré roman

J'ai tout lu. Mon aide sera modérée et intéressée (je me penche actuellement sur la récup raid, mais je n'en ai pas encore réalisé). Je relis tous demain, mais d'ors et déjà :
1/ Envoie moi un MP j'ai trouvé un doc intéressant sur la récup Raid0 (en anglais) mais je n'ai pas penser à noter le lien. Je te le retourne par mail.
2/ Je ne connais pas le Thecus. Tu ne sais pas quel était le fs sur ton raid ?
3/ Après les deux passages de e2fsck -y, tu peux d'emblée recommencer tes images saines. On arrivera à rien de bon à partir de celles-cis à mon avis.
4/ Sur le blog de cep il y a un article sur le montage d'un fs endommagé, et l'explication sur les super de secours etc...
5/ à noter pour plus tard (christophe grenier ne t'en a pas parlé ?) qu'il existe une version beta de testdisk/photorec (pas eu de problème de stabilité) qui est justement... statique.
6/ En réfléchissant et en retournant ton problème dans tous les sens, je me dis que la question essentielle est de savoir :
*ce qui s'est produit lorsque tu as installé ton disque seul hors de ton NAS
*pourquoi ton NAS n'a plus reconnu ton RAID dès lors
*ce qu'a fait ton NAS au boot.
7/ Bien sûr tu as déjà envisagé et éliminé la possibilité de faire appel à une entreprise spécialisée dans ce domaine ?

chown6471 · Le 02/05/2010, à 13:53

Rmy,

Merci beaucoup pour l'attention (et pour l'effort de lecture: un vrai boulot) que tu as porté à mon cas.

Désolé, je fais encore un roman, mais il y a des points qui nécessitent quelques compléments d'infos, car effectivement, tu poses les questions essentielles dès le départ, et j'ai du faire des coupes dans l'historique du post précédent :-)

(1) Doc recup RAID-0: ok je t'envoie un MP dès que j'ai trouvé comment faire. Je n'ai pas une très grande habitude des forums... j'ai oublié d'évoluer :-) Ce doc sera certainement très utile. Eventuellement, si pas trop long, je pourrai essayer de le traduire.

(2) A confirmer: il s'agirait d'un EXT-3, chuis pas sûr...

Dans l'étape "(c) PROBLEME RAID: assemblage RAID incohérent", j'avais initialement un peu bataillé pour maîtriser l'outil mdadm, qui est, à ma connaissance l'outil standard pour la gestion RAID.

(A confirmer) En utilisant:

mdadm --assemble --scan

mdadm réalise l'assemblage en effectuant un scan des devices (ou partitions), et pour chaque device, en regardant avec quel autre device il s'assemble. Ce qui est intéressant dans cette commande, c'est que mdadm renvoie des infos sur chaque device. Et c'est là, pendant l'exécution de cette commande que mdadm m'avait renvoyé une info du genre "disque 1 seems to contain an EXT2 partition".

Cette info, s'était trouvée confirmée graphiquement dans palimpset quand mes 4 disques RAID branchés en USB était affichés dans l'arbre Palimpset. On voyait bien dans l'arbre une partition EXT2 sous le disque 1.

Autre point: dans les diagnostics que j'effectue vers la fin de mon roman, e2fsck m'indique clairement: e2fsck: Illegal inode number lors de la vérification du journal ext3 pour /dev/md0

e2fsck semble donc partir sur l'idée qu'il s'agit d'une partoche journalisée EXT3...!!?? Si cette info est fiable, le système de fichier de mon RAID serait donc EXT3..?

(3) Ca, c'est sûr :-)

Depuis la "réparation / destruction" de mon premier lot d'images disques, j'ai déjà préparé un nouveau lot de 4 images qui (nous) attendent pour de nouvelles aventures !!!

La façon de fonctionner est très simple: on choisit une stratégie de réparation, on l 'applique, si ca marche tant mieux, sinon, je recrée 4 images (env. 15 heures nécessaires, bon, 24 heures), et on essaye une autre stratégie...

Donc, aujourd'hui dimanche 2 mai, il y a 4 images toutes "neuves", prêtes à l'emploi. Elles n'attendent que tes ordres :-)

(4) Je vais aller voir. Il me semble effectivement avoir vu cet article très intéressant.

Pour être tout à fait honnête, il faudrait idéalement que cette méthode fonctionne... Si on part du postulat que les données ne sont pas détruites mais que des superblocs ont pu être accidentellement modifiés par mdadm et/ou lorsque j'ai (stupidement) remis mes disques dans le NAS, a priori on pourrait normalement compter sur ces superblocs de secours pour récupérer la TP.

Je ne dis pas que cela sera vraiment trivial, et évident... Mais bon... Les superblocs de secours semblent être une piste sérieuse à exploiter.

C'est l'hypothèse que j'avais en mars, je crois. J'étais tombé sur un blog anglais qui expliquait cela, et j'avais fait quelques essais rapidement, et malheureusement sans succès. Il semblait que les superblocs n'étaient pas disponibles...

Il faudra ré-essayer cette technique, pour moi, la piste 1 à tenter. Je suis certain que je m'y suis mal pris la première fois.

(5) Alors là, tu vas rire (ou pas!).

Les emails de Christophe sont dans mon laptop, qui est... en réparation :-)

Loi de Murphy, quand tu nous tiens....

De mémoire, et sous réserve que je ne me trompe pas dans ce qu'il m'a dit: mon échec à cross-compiler PhotoRec sur architecture ARM lui avait paru étrange, mais il était possible qu'il y avait quelque chose qui ne marchait pas lors du linkage final des binaires dans le script.

Sans doute, et j'en suis persuadé, il est possible de compiler PhotoRec en statique moyennant un bidouillage quelconque et de le faire tourner dans le NAS. Le problème n'est pas PhotoRec, le problème, c'est moi... Dans un état d'affolement des premiers jours, j'avais déjà pris la (mauvaise) décision de remonter le RAID et d'utiliser PhotoRec dans un Linux plus conventionnel...

Conclusion: l'utilisation de PhotoRec dans le Thecus n'est pas d'actualité pour l'instant, vu les âneries que j'ai faites entre-temps. Cependant, et dans le cas incroyable où je parviendrais à récupérer mes données, j'ai bien dans l'idée d'essayer de compiler complètement PhotoRec et d'en faire un plug-in installable sur le Thecus. Ce serait chouette de disposer d'un tel outil sur ce NAS...

En fait, Christophe a été beaucoup plus gentil que cela: je lui ai laissé mon "roman", il m'a proposé un tool perso de remontage RAID à adapter et à recompiler pour essayer de remonter mon RAID sans utiliser mdadm. Mon laptop (et son email dedans) a lâché peu de temps après... J'ai l'intention d'utiliser son tool dès que je récupérerai mon laptop comme une alternative à mdadm. Mais bon, dans mon cauchemar perso, il faut également que je récupère mon laptop et les infos que m'a données Christophe...

(6) Ben oui.... exactement les deux mêmes questions fondamentales que je passe mon temps à ressasser.

(a) Disque tout seul assemblé dans mdadm:

mdadm m'a grondé en me disant que le RAID est incomplet. Logique, vu qu'un RAID-0, à la différence d'un RAID-5 par exemple, nécessite tous ses disques pour être complet. Pas de mode dégradé en RAID-0...

Je ne suis pas vraiment inquiet sur ce qui s'est passé: je crois en fait, que rien ne s'est passé. mdadm a seulement refusé d'assembler un disque RAID-0 seul. Point barre.

En revanche, et je n'ai pas mentionné ce point dans mon historique, car assez difficile à décrire, c'est peut-être ce qui s'est passé lors de mes tentatives suivantes le jour 0, qui pourrait avoir eu un impact.

En effet: après mon essai initial d'assemblage d'1 disque, et une fois mes 4 disques correctement branchés en USB, j'ai essayé d'assembler mon RAID-0 avec mdadm.

L'outil mdadm est très puissant, mais, il faut avouer qu'il est également déconcertant en raison de sa flexibilité qui aboutit à différentes façons de créer / assembler un RAID. C'est indéniablement une source de confusion pour beaucoup d'utilisateurs, et même pour des sysadmins pourtant rompus à ce type d'exercice... Bon... je n'essaye pas de me justifier, mais disons pour faire court qu'il est très peu probable qu'avec N disques RAID, on puisse du premier coup monter son RAID avec succès dans un état de fonctionnement immédiat... Il faut chercher un peu. C'est ce que j'ai fait.

J'ai essayé plusieurs techniques, et pour cela, je me suis référé à un tutorial Ubuntu (je dois trouver l'URL, car je me suis promis de demander à l'auteur d'apporter quelques mises en garde), et notamment concernant la phase finale: désassemblage + démontage des disques physiques. En effet: j'ai assez rapidement réussi à monter mon RAID avec mdadm, mais le désassemblage du RAID avec la commande mdadm --stop /dev/md0 ne semblait pas fonctionner correctement. Dans ce tuto, l'auteur préconisait d'utiliser un switch de la commande mdadm nommée "zero-superblock" qui permettait (selon lui) de garantir une libération correcte des ressources disques.

Tuto Ubuntu en ligne, a priori digne de foi? Ni une ni deux, je m'exécute: j'ai utilisé cette option, et immédiatement après, lorsque j'ai voulu recommencer un assemblage RAID, mdadm m'indiquait que les superblocs RAID n'étaient plus là!!!!

De là à considérer que mentionner la technique du zero-superblock est une idiotie, il y a un pas, mais avec le recul, et avec un peu plus de connaissances sur le RAID, je crois comprendre que le zero-superblock a avant tout une fonction de reset des meta-informations logiques qui lient plusieurs devices les uns aux autres dans un ensemble RAID. En clair: quand les superblocs ont été resetés, mdadm serait incapable de savoir quels disques sont assemblés avec quels disques. Donc au minimum, il conviendrait que l'auteur du tuto mette en garde sur les effets de cette option qui peut vraiment mettre l'utilisateur lambda en difficulté.

Donc, une fois cette belle "boulette" commise, et après beaucoup de remerciements (intérieurs) à l'auteur du tuto pour l'absence de mise en garde sur cette technique, j'ai écumé les forums sur mdadm. J'ai trouvé différents moyens pour regénérer les superblocs de mon RAID. Mais c'est toujours la même histoire: dès qu'on a un RAID conventionnel genre RAID-5, il y a plein de techniques. Quand on tourne sur un RAID-0, c'est une autre affaire... D'ailleurs pour les superblocs RAID, avec un RAID-5, la technique consiste plus ou moins à utiliser une astuce avec mdadm qui force mdadm à regénérer des superblocs sur les disques qui n'en n'ont pas. Mais çà, par exemple, ça marche bien avec un RAID comme le RAID-5 car on peut le dégrader... Dans le cas du RAID-0, c'est une autre paire de manches.

Conclusion: je suis quasi-certain d'avoir réussi a regénérer les superblocs RAID de mes disques en m'inspirant de ces différentes sources d'infos, mais savoir exactement comment j'ai fait.... euh.... that is the question!!!

Voici donc les autres questions que je me pose:

- Comment ai-je réussi à regénérer les superblocs RAID?
- Comment les superblocs RAID sont-ils organisés sur un RAID-0?
- Est-ce que j'ai (mdadm a) bousillé quelque chose créé par le NAS en regénérant les superblocs RAID?
- Est-ce que les superblocs RAID générés par mdadm sont compatibles avec ceux du NAS? Il semble en effet que les superblocs RAID répondent à une spécification, et qu'il existe plusieurs versions de cette spécification...
- Y a t-il un lien entre les superblocs RAID et les superblocs d'un système de fichiers EXT2 ou EXT3 (manque de connaissances et de sources d'infos)?

Au final, donc, j'ai bien obtenu 4 disques qui semblent cohérents du point de vue mdadm, car mdadm a finalement à nouveau accepté d'assembler mes disques...

Mais...

A Jour 0, lorsque je décide après ces péripéties de remettre ces 4 disques dans le NAS, est-ce que les superblocs RAID que j'ai regénérés sont toujours compréhensibles par le NAS? Naïvement, j'ai pensé que oui, mais intuitivement, si j'ai voulu pratiquer ce test, c'est que j'ai pris peur, et que j'avais quand même un doute après avoir regénéré les superblocs RAID...

Vu l'échec que j'ai rencontré en remettant les disques dans le NAS j'ai pris comme acquis l'idée qu'un RAID traité (et modifié?) par mdadm n'est pas compréhensible dans le NAS Thécus.

Il faudra donc que j'essaye à nouveau d'obtenir des infos avec Thecus. J'ai déjà essayé (envois de tickets sur leur support), et jusqu'à présent, restés sans réponse. Mais là aussi, par où commencer??? Il y a beaucoup de questions. Et s'ils ne donnent aucune réponse à la première....

Si des utilisateurs Thécus en savent plus que moi sur ce sujet, n'hésitez pas à me faire part de vos connaissances....

(b) Qu'a fait le NAS lors de son boot?

Deuxième question essentielle, en effet. Dans mon historique du post précédent, j'ai essayé de livrer quelques hypothèses. Mais c'est vrai, aucune certitude.... La réponse à ta question (a) ci-dessus et la conséquence sur cette question (b) pourrait aussi être un élément de réponse.

Mais il n'y a qu'un moyen de le savoir: obtenir l'info chez Thécus...

(7) Mmmmhhhh.... :-/

Oui, j'ai envisagé, et j'envisage potentiellement, en ultra-ultra-dernier recours de faire appel à une société spécialisée. Je ne veux fermer aucune porte, car oui, plus de 18 mois de travail et d'efforts partis comme ça, on ne peut pas tirer tout de suite un trait dessus sous l'effet d'une impulsion non réfléchie.

Psychologiquement, c'est très difficile à encaisser, car pour pouvoir développer ce projet perso, j'ai du faire des choix de sacrifices professionnels, en l'absence de financements (dont je ne veux pas d'ailleurs, pour garantir la gratuité du projet et aucune main-mise extérieure).

Si je fais le bilan de cette situation (qui n'a rien à voir avec la technique), je considère donc que la valeur de mon travail (ne serait-ce qu'en termes de jours passés dessus) vaut la peine d'envisager le recours à une telle société.

Le problème que j'ai pour l'instant, et je suis ouvert à toute proposition sérieuse, c'est que les offres de services proposées par ces sociétés semblent assez floues, pour ne pas dire bizarre... Peut-être ai-je mal regardé, mais, bon... je suis pour l'instant un peu circonspect. Si tu connais des boîtes sérieuses et honnêtes, je n'hésiterai pas, le cas échéant, à envisager cette possibilité.

Mais pour l'heure, je veux, enfin j'essaye, de rester optimiste: ne perdons pas de vue qu'on parle de disques sains. Au pire une ou des erreurs de manips auraient pu corrompre certaines données des systèmes de fichiers, mais je suis (pour l'instant) très peu enclin à croire qu'un formatage implicite des disques s'est produit dans le NAS. Si cela est vérifié, et vu l'extraordinaire trésor de conseils et d'entraide, et des outils très puissants (par ex: testdisk) je crois qu'il me reste encore quelques questions auxquelles je dois répondre, et quelques cartouches de tests et de manips que nous pourrons tirer avant de nous déclarer définitivement vaincus!!

Je suis assez convaincu que 99% de la clé réside en fait dans la réflexion et dans le raisonnement sur ce problème, bien plus que sur le nombre de manipulations à effectuer. S'il y a une clé, elle est certainement sous mon nez, il suffit de la saisir, et je ne la vois pas...

TODO

Je vais examiner plus en détail les points que tu as mentionnés (avec une check-list), et je reviens dès que j'ai du neuf en termes d'infos. Je continue à surveiller toute suggestion que tu auras à me soumettre. Pour mémo: 4 images disques sont déjà prêtes pour des manips...

On pourrait peut-être exécuter deux campagnes de manips successives: la PISTE 1 (superblocs de secours), puis la PISTE 2 (testdisk).

Qu'en penses-tu?

Merci à toi

rmy · Le 03/05/2010, à 12:57

J'aimrais bien faire l'inverse (je prends directement la dernière question car connaissant mal les RAID, hormis un peu en théorie je ne peux répondre à toutes tes questions précédentes concernant les superblocs RAID par rapport aux super ext2/3).

Du coup, si je ne me trompe pas, lorsque les disques d'un RAID sont assemblés, l'ensemble est vu comme un seul device/système de fichier, est-ce exact ?

Si c'est le cas, un fois placée tes images sur les /dev/loop et assemblé ton raid avec mdadm (dont je ne connais rien, jusqu'à l'existence, mais je vais me renseigner), essaye de voir ce que dit testdisk. Commence par une analyse standard voir ce qu'il détecte comme FS et voir aussi si d'emblée il arriverait à accéder à la liste des fichiers avec l'un d'eux (je crois d'ailleurs qu'il s'appuye sur les superblocs de secours). Testdisk n'écrit rien si tu ne lui demandes pas, dans le log on aura les super, on pourra donc s'appuyer dessus pour le montage de la partition endommagée.

Vu l'ampleur que va prendre cette tentative de récup, je te propose d'ouvrir un nouveau fil spécifique, d'y copier/coller les posts précédents, et de linker ici. Ce post me sert plus d'archive en attendant le jour où j'aurais le temps et le courage (et l'impression d'avoir une vu globale suffisante) pour pouvoir faire un tuto (plutôt au pluriel pour distinguer les cas) dans le wiki.

Dès que tu as mis le lien ici, je ferai un appel le plus large possible autour de moi des quelques personnes que je sais avoir des connaissances pointues pour les inviter à parcourir ton fil de discussion. J'espère que l'on pourra s'en sortir.

Dernière modification par rmy (Le 03/05/2010, à 12:58)

Elven · Le 06/06/2010, à 22:44

Bonjour,

je ne sais pas où poster ça donc plutôt que de créer un autre topic.
Dite-moi si je dois, et où.

Mon disque dur de mon PC portable ne marche plus.
J'ai voulu utilisé cette commande sur ma clef mais sans changer le "sda" :

dcfldd if=/dev/zero of=/dev/sda conv=notrunc

Mais je me suis arrêté à 1Gb ou 1Mb je ne sais plus. Mais ça a suffit pour que je ne puisse plus aller dessus. Le dd fait 250 Go.
J'ai une partition home et une pour ubuntu. Mais aucun accès à l'une ni à l'autre.

Sous Lucid

Utilitaire de disque :

secteurs déféctueux 65537

sudo dd if=/dev/sda bs=512 count=1 | hexdump -C

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 enregistrements lus
1+0 enregistrements écrits
00000200
512 octets (512 B) copiés, 0,022216 s, 23,0 kB/s

Donc là je suis sur live CD Lucid.

J'ai essayé d'instaler testdisk mais il me dit que c'est impssible de trouver le packet. Que ce soit dans la console où en cliquant sur le lien sur la page wiki pour le télécharger. De même pour Photorec.

Donc si vous avez des idées j'en serais ravi bien sûr.

rmy · Le 07/06/2010, à 23:59

Que ce soit 1 Mo ou 1 Go tu as écris des zéros sur le MBR de ton disque. Ta table de partition est donc morte. Depuis le liveCD de lucid tu peux utiliser la version static de testdisc (la beta 6.12) qui ne nécessite as d'installation. Une recherche approffondie avec testdisk devrait te permettre de retrouver tes anciennes partitions. La première sera sans doute dure à monter, la seconde devrait être intacte avec un peu de chances.

Si tu as peur de faire des bêtises supplémentaires, je peux m'en occuper, mais comme je ne fais pas de pub sur le forum, je te laisse le soin de me contacter en MP dans ce cas. Sinon, télécharge testdisk, lance le, fais bien attention de ne rien écrire sur ton disque (pas de write pour l'instant) et poste ici (ou ailleurs, mais donne le lien dans ce cas) les résultats que te donne testdisk. Au moindre doute, demande.

Nasman · Le 08/06/2010, à 07:33

Elven a écrit :

secteurs déféctueux 65537

Hasard ou erreur du fait d'un dépassement de capacité 65537 = 2**16 +1

Elven · Le 08/06/2010, à 10:00

Nasman : chouette opération mais je ne vois pas ce que tu veux me dire.

rmy : j'ai installer testdisk avec le lien sur le wiki. Sur une partition de 1Go il me reste presque plus de mémoire. J'ai toujours un message qu'apparaît. Faudrait que je refasse le live sur les 4Go de la clef.

Je mets le lien vers mon topic :

http://forum.ubuntu-fr.org/viewtopic.php?id=401894

Avec testdisk je retrouve les partitions :

Disk /dev/sda - 250 GB / 232 GiB - CHS 30402 255 63
     Partition               Start        End    Size in sectors
* Linux                    0   1  1  3880 254 63   62348202
P Linux                 3881   0  1  5206 254 63   21302190
L Linux                 5207   1  1 30098 254 63  399889917
L Linux Swap           30099   1  1 30400 254 63    4851567

et quand je fais "p" pour aller dans la première partition j'ai ça : No file found, filesystem seems damaged.

Quand tu dis que tu peux t'en occuper, c'est comment ? En prenant la main sur mon PC ?

Regression · Le 15/06/2010, à 23:59

A tout hasard de la lecture utile pour les disques WD :

http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sector_Hard_Drives

http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/index.html?ca=dgr-lnxw074KB-Disksdth-LX

http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5324

rmy · Le 16/06/2010, à 03:01

merci, j'y ajoute ce topic sur les WD / parquage des têtes

loreleil.747 · Le 17/07/2010, à 22:31

Bonjour,

@ rmy si tu passe par là, j'en serais ravît.

Et si qui plus est, tu m'invites à la table des grands, une lumière apparaîtra !

17 années d'archives perdues (120 Go) sur dd externe !

Ne souhaitant pas pollué ton fil j'ai posté ici : http://forum.ubuntu-fr.org/viewtopic.ph … 2#p3608592

Merci à vous tous !

Dernière modification par loreleil.747 (Le 04/08/2010, à 11:56)

loreleil.747 · Le 04/08/2010, à 18:31

Voici comment mon fil http://forum.ubuntu-fr.org/viewtopic.php?pid=3608592#p3608592 aurait dû se dérouler.
Je crois.
Dans le cas ou j'aurai fournit les bonnes informations, et appliquer les directives de rmy.

Je relirai et corrigerai les erreurs d'appellations des /dev/sd(x), ainsi que les code(s) qui en découles. ( c'est assez hard de faire cette mise à jour )

ps: merci de ta collaboration de tshirtman,

merci pour les infos matériels Brunod, ( mp à suivre )

merci à vous tous qui êtes passé par là.

Un grand MERCI, rmy. .... !
Sans oublié Christophe Grenier.

post #1

loreleil.747 a écrit :

Bonjour,

Une erreur d'inattention lors d'une création d'une nouvelle partition sur dd externe ( 1 To ) ici il s'agit de /dev/sdg

J'ai perdus 120 Go de données ( administratives, dossiers perso.,scan, jpg, odt, txt, (boulot: xrs, xry, xrm,) vidéos, courriers, etc ... etc... ) la cata pour moi. Mais tout est relatif.

Avril 2010 > suite à mon erreur,voici ma démarche.

Récupération de données perdues > http://forum.ubuntu-fr.org/viewtopic.ph … 28#p719028 et là je n'est pas pris le temps d'approfondir le sujet ni même suivit l'excellent tuto de rmy. ( ne pas réécrire sur le disque concerner )

Dans l'affolement et de part obligation professionnelle, je me suis lancer tête baisser.
Le bourrin ....

Sur mon dd externe sdg j'ai créer une nouvelle partition et lancer photorec.

Et j'ai repris la lecture " Bilan : comment récupérer des données perdues " de rmy

Trop tard. J'ai stopper, en espérant que les dommages ne portent pas à conséquences pour mes données, enfin j'ose le croire !
Depuis j'ai investit pour un deuxième dd externe d'1 To.

Pour info:

root@loreleil-desktop:/home/loreleil# fdisk -l

Disque /dev/sda: 41.2 Go, 41174138880 octets
255 têtes, 63 secteurs/piste, 5005 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0xe03dea09

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1   *           1          19      145408   83  Linux
La partition 1 ne se termine pas sur une frontière de cylindre.
/dev/sda2              19        5006    40060929    5  Etendue
/dev/sda5              19         201     1464320   82  Linux swap / Solaris
/dev/sda6             201         688     3905536   83  Linux
/dev/sda7             688        1295     4881408   83  Linux
/dev/sda8            1295        3484    17576960   83  Linux
/dev/sda9            3484        4092     4881408   83  Linux
/dev/sda10           4092        4335     1951744   83  Linux
/dev/sda11           4335        4882     4393984   83  Linux
/dev/sda12           4882        5006      998400   83  Linux

Disque /dev/sdb: 1000.2 Go, 1000204886016 octets
255 têtes, 63 secteurs/piste, 121601 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x0c7edacc

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb3           12918       19291    51199155    7  HPFS/NTFS


Disque /dev/sdg: 1000.2 Go, 1000204886016 octets
255 têtes, 63 secteurs/piste, 121601 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identifiant de disque : 0x85169e07


Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdg1               1       32589   261771111   83  Linux
/dev/sdg2           32590       59471   215929665    7  HPFS/NTFS

loreleil@loreleil-desktop:~$ sudo gpart /dev/sdg

[sudo] password for loreleil: 

Begin scan...
Possible partition(Windows NT/W2K FS), size(210868mb), offset(255635mb)
End scan.

Checking partitions...
Partition(OS/2 HPFS, NTFS, QNX or Advanced UNIX): primary 
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX)
   size: 210868mb #s(431859330) s(523542285-955401614)
   chs:  (1023/254/63)-(1023/254/63)d (32589/0/1)-(59470/254/63)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

TestDisk:

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
* Linux                25496   0  1 63745 254 63  614486250 [SAUVExt300Go]
P Linux                63746   0  1 76820 254 63  210049875
P Linux                76821   0  1 84469 254 63  122881185 [rdiff-backup]



Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
EXT4 Large file Sparse superblock, 314 GB / 293 GiB

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
D HPFS - NTFS              0   1  1 25495 254 63  409593177
D HPFS - NTFS              0   1  1 121600 254 63 1953520002
D Linux                25496   0  1 63745 254 63  614486250 [SAUVExt300Go]
D HPFS - NTFS          32589   0  1 59470 254 63  431859330
D Linux                63746   0  1 76820 254 63  210049875
D Linux                76821   0  1 84469 254 63  122881185 [rdiff-backup]



Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
NTFS found using backup sector!, 209 GB / 195 GiB

Il était temps d'arrêter mes conneries.

Et il souhaitable d'utiliser dans mon cas et qu'en pensez vous ? Via: http://doc.ubuntu-fr.org/dd

> Cloner un disque dur en entier ( valable pour un dd externe je suppose ) : ici il s'agit de sdg à récupérer vers sdb

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

> Copie bit à bit d'un support : créer un fichier image parfait

dd if=/dev/sdg of=/home/user/sauvegarde/dev/sdb1.iso

> Où autres ?

> Et comment procéder ? Sans commettre l'irréparable !

Puis je formaté entièrement sdb. Sous quel format ( fat32, ntfs, etx2, ext3, ext4, où autres ) sachant que mes sauvegardes archives sur sdg sont à 90% en ntfs

No stress ! Euh pas évident !

En espérant vous avoir fournit quelques infos élémentaires pour un début de solutions envisageables.

Merci à vous.

post #28

rmy a écrit :

Heu... bonsoir ^^'
Il semble que l'on attende après moi ?
Je n'ai pas grand chose à ajouter, tout a été dit. Si il faut confirmation, puisque tu as acheté un disque exprès, la première chose à faire est la sauvegarde de l'état initial. Dans un cas comme le tiens, la copie d'un disque sur l'autre me parait idéale et contentera aussi bien Tshirtman sur le travail avec testdisk que Hoper si il veut se fier aux outils propriétaires.
Vu le prix des derniers, je te propose de commencer par les solutions libres, et si ça ne suffit pas, alors Hoper t'apportera de l'aide.
Pour la proposition de te tourner vers "alternative informatique", à laquelle tu as répondu en y préférant mon tuto… j'en suis très flatté… mais pour dire le vrai j'aimerais beaucoup aller travailler dans cette entreprise (c'est un autre nom de chronodisk) pour compléter mes connaissances et compétences dans ce domaine. Qui sait, peut-être pour 2011 ?
Revenons à ton cas.
dd c'est bien, mais c'est stressant parce que tu ne sais jamais où il en est. Je te conseille d'utiliser ddrescue à la place, en plus tu peux reprendre en cas d'arrêt, et si il y a des erreurs dûes à des problèmes matériels ils seront gérés.

post #116

loreleil.747 a écrit :

Salut rmy,
Qu'est-ce qu'on cherche ?
toutes mes archives sauvegardées sur une partition NTFS : provenant de (x) dd internes sous os win.... comprenant des ; documents administratifs, scan, schémas électriques, vidéos, photos, logiciels, etc.... représentant plus de 120 Gio soit 17 années " d'archives ".
a) Sur le dd externe " données perdus " il y a eu plusieurs partitions créer :
b) étant le dd de " la copie conforme via ddrescue "
1° à l'origine une partition ntfs : " mes archives "
2° une partition en ext 3 où 4 qui fût supprimé. Dans laquelle j'avais effectué des sauvegardes avec Back in Time : supprimé avant ma boulette
3° ma boulette : ( je voulais créer une nouvelle partition en ext4,) Hors, en faite j'ai créer une nouvelle table de partition.

Ce qui a eu pour conséquences la perte total de " mes archives ".
4° ayant compris trop tard ma boulette, et ayant suivit je ne sais plus quels tutos sur photorec, j'ai très rapidement décidé de créer une partition sur a)pour effectuer une récupération de " mes archives " via photorec en ext. où ntfs ( je penche plutôt sur le ext 3 où 4 )
5° j'ai lancé photorec, et l'est arrêter assez vite prenant conscience que j' écrasé " mes archives " d'où Rdiff ( je crois ) contenant encore à ce jour des dossiers " recup_dir 1 à recup_dir 22 . Soit environ 3,61 Gio
C'est ce que je retrouve après avoir lancer Tesdisk. ( sauf erreur )
ps : j'investis pour un nouveau dd externe de 1 To au plus tard samedi après midi.
Je ne sais pas si je suis clair sur se coup là.
Amicalement, loreleil

post #117

rmy a écrit :

Super ! C'est plus clair !
Je prends le temps de détailler un peu plus tard, mais en tout cas l'investissement d'un deuxième dd de 1To ne me paraît pas utile pour la récup.

post #28

après avoir installé ddrescue

il te faudra donc faire :

sudo ddrescue /dev/sdg /dev/sdb copie.log

donne le retour de cette commande quand ce sera fini (demain…)

post #55

loreleil.747 a écrit :

Bonsoir à vous,

Ainsi :

sudo ddrescue /dev/sdb /dev/sdc copie.log

Qui me donne actuellement :

loreleil@loreleil-desktop:~$ sudo ddrescue /dev/sdb /dev/sdc copie.log


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:   101191 MB,  errsize:       0 B,  current rate:   15007 kB/s
   ipos:   101191 MB,   errors:       0,    average rate:   16376 kB/s
   opos:   101191 MB,     time from last successful read:       0 s
Copying non-tried blocks...

No stress ........ !

post #57

rmy a écrit :

bonne nuit, ça tourne.

post #60

loreleil.747 a écrit :

Bonjour,

De retour plutôt que prévu.

loreleil@loreleil-desktop:~$ sudo ddrescue /dev/sdb /dev/sdc copie.log


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:        1 TB,  errsize:       0 B,  current rate:   14483 kB/s
   ipos:        1 TB,   errors:       0,    average rate:   16313 kB/s
   opos:        1 TB,     time from last successful read:       0 s
Finished                   
loreleil@loreleil-desktop:~$

Bizarre, dans propriété de sdc inchangé. Et graphiquement, rien ?

No stress .......

post #62

rmy a écrit :

loreleil, no stress, c'est bien de le dire, mais il faut le faire. Tu veux aller plus vite que la musique.
Pour l'instant, on a juste fait une copie de sauvegarde.
Débranche ton disque d'origine, garde le dans un endroit protégé (pas de chute, de choc, d'electricité statique, d'eau, etc...)
Maintenant on va travailler sur /dev/sdc, mais tu vas le débrancher aussi et le rebrancher puis donner le retour de sudo sfdisk -luS (et pas obligé de mettre tout le reste, juste ça suffira)

post #63

loreleil.747 a écrit :

Bonsoir rmy,

Voici:

loreleil@loreleil-desktop:~$ sudo sfdisk -luS
[sudo] password for loreleil: 

Disque /dev/sda : 5005 cylindres, 255 têtes, 63 secteurs/piste
Attention : la partition étendue ne débute pas sur une frontière de.
cylindres. DOS et Linux interpréteront les contenus différemment.
Unités= secteurs de 512 octets, décompte à partir de 0

   Périph Amorce  Début       Fin   #secteurs Id  Système
/dev/sda1   *      2048    292863     290816  83  Linux
/dev/sda2        294910  80416767   80121858   5  Etendue
/dev/sda3             0         -          0   0  Vide
/dev/sda4             0         -          0   0  Vide
/dev/sda5        294912   3223551    2928640  82  Linux swap / Solaris
/dev/sda6       3225600  11036671    7811072  83  Linux
/dev/sda7      11038720  20801535    9762816  83  Linux
/dev/sda8      20803584  55957503   35153920  83  Linux
/dev/sda9      55959552  65722367    9762816  83  Linux
/dev/sda10     65724416  69627903    3903488  83  Linux
/dev/sda11     69629952  78417919    8787968  83  Linux
/dev/sda12     78419968  80416767    1996800  83  Linux

Disque /dev/sdb : 121601 cylindres, 255 têtes, 63 secteurs/piste
Unités= secteurs de 512 octets, décompte à partir de 0

   Périph Amorce  Début       Fin   #secteurs Id  Système
/dev/sdb1            63 523542284  523542222  83  Linux
/dev/sdb2     523542285 955401614  431859330   7  HPFS/NTFS
/dev/sdb3             0         -          0   0  Vide
/dev/sdb4             0         -          0   0  Vide
loreleil@loreleil-desktop:~$

Merci.

post #64 & 119

rmy a écrit :

Bien, maintenant il va falloir commencer à se mettre au boulot, et du coup, "No Stress", uisque même en cas de bourde, tu peux recommencer cette première opération de copie du disque.
sudo testdisk /dev/sdb

rmy a écrit :

Ensuite [Proceed] > [Intel ] Intel/PC partition > en modifiant quelques options dans testdisk :
[ Options ] Expert mode : yes
Cylinder boundary : No
Allow partial last cylinder : No
Dump : No
[ Ok ]

>[ Analyse ] > copié collé de ce que t'affiche l'écran (pas Ctrl+C pour copier, ça interromp le programme )
[Quick Search] > copié collé de ce que t'affiche l'écran.
et enfin, un peu plus long,
[Continue]> [Deeper Search] > copié collé de ce que t'affiche l'écran

post #136

loreleil.747 a écrit :

Voilà : Testdisk > Expert > [Deeper Search]

Terminé ce jour à 20h25 ! ..........

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
D HPFS - NTFS              0   1  1 25495 254 63  409593177
D HPFS - NTFS              0   1  1 121600 254 63 1953520002
D Linux                25496   0  1 63745 254 61  614486248 [SAUVExt300Go]
D HPFS - NTFS          32589   0  1 59470 254 63  431859330
D Linux                63746   0  1 76820 254 60  210049872
D Linux                76821   0  1 84469 254 62  122881184 [rdiff-backup]






Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
NTFS found using backup sector!, 209 GB / 195 GiB

No stress ................................. .... ......:D !

Je " croise les doigts " .................. !

post #143

loreleil.747 a écrit :

Bonjour,

On progresse.

- P : permet de lister les répertoires et fichiers présents sur une partition, et ainsi non seulement de confirmer qu’on a récupéré la bonne partition (et de se rassurer quand on voit les données importantes qu’on voulait récupérer) mais également, dès ce stade, de copier les données à récupérer sur n'importe quelle autre partition ou disque dur :

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
D HPFS - NTFS              0   1  1 25495 254 63  409593177
D HPFS - NTFS              0   1  1 121600 254 63 1953520002
D Linux                25496   0  1 63745 254 61  614486248 [SAUVExt300Go]
D HPFS - NTFS          32589   0  1 59470 254 63  431859330
D Linux                63746   0  1 76820 254 60  210049872
D Linux                76821   0  1 84469 254 62  122881184 [rdiff-backup]





Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
NTFS found using backup sector!, 209 GB / 195 GiB

Testdisk avec l'option P: list files, me donne pour infos ceci :

    HPFS - NTFS              0   1  1 25495 254 63  409593177
Directory /

dr-xr-xr-x     0     0         0  9-Dec-2009 09:55 .
dr-xr-xr-x     0     0         0  9-Dec-2009 09:55 ..
dr-xr-xr-x     0     0         0 18-Dec-2009 15:11 copie  usb 16 GO
dr-xr-xr-x     0     0         0 18-Dec-2009 11:57 COPIE CLES 8GO bis
dr-xr-xr-x     0     0         0 15-Mar-2010 13:38 COPIE CLÉS 8 Go
dr-xr-xr-x     0     0         0  7-Dec-2009 08:29 COPIE COMPACT 1
dr-xr-xr-x     0     0         0 14-Dec-2009 17:56 COPIE F fig. N
dr-xr-xr-x     0     0         0 14-Dec-2009 18:01 COPIE G fig. N
dr-xr-xr-x     0     0         0  7-Dec-2009 08:27 COPIE GRIS
dr-xr-xr-x     0     0         0  7-Dec-2009 16:25 COPIE HP COMPACT
dr-xr-xr-x     0     0         0 26-Oct-2009 16:12 Musiques
dr-xr-xr-x     0     0         0 26-Oct-2009 16:10 RECYCLER
dr-xr-xr-x     0     0         0 22-Dec-2009 11:20 Start Downloader
dr-xr-xr-x     0     0         0  9-Dec-2009 09:53 System Volume Information
                                                   Next
Use Right arrow to change directory, c to copy,
    q to quit

     HPFS - NTFS              0   1  1 121600 254 63 1953520002



Can't open filesystem. Filesystem seems damaged.





[  Quit  ]
                               Quit this section

     Linux                25496   0  1 63745 254 61  614486248 [SAUVExt300Go]
Directory /

drwxrwxrwx  1000  1000      4096 10-Mar-2010 13:04 .
drwxrwxrwx  1000  1000      4096 10-Mar-2010 13:04 ..
drwx------     0     0     16384  5-Mar-2010 16:45 lost+found
drwxr-xr-x  1000  1000      4096 10-Mar-2010 13:04 backintime
drwxr-xr-x  1000  1000      4096  9-Mar-2010 09:34 Sauvegarde Systeme

     HPFS - NTFS          32589   0  1 59470 254 63  431859330
Directory /

dr-xr-xr-x     0     0         0 19-Apr-2010 13:35 .
dr-xr-xr-x     0     0         0 19-Apr-2010 13:35 ..
dr-xr-xr-x     0     0         0 20-Apr-2010 11:35 recup_dir.1
dr-xr-xr-x     0     0         0 20-Apr-2010 11:37 recup_dir.10
dr-xr-xr-x     0     0         0 20-Apr-2010 11:37 recup_dir.11
dr-xr-xr-x     0     0         0 20-Apr-2010 11:37 recup_dir.12
dr-xr-xr-x     0     0         0 20-Apr-2010 11:37 recup_dir.13
dr-xr-xr-x     0     0         0 20-Apr-2010 11:37 recup_dir.14
dr-xr-xr-x     0     0         0 20-Apr-2010 11:37 recup_dir.15
dr-xr-xr-x     0     0         0 20-Apr-2010 09:27 recup_dir.16
dr-xr-xr-x     0     0         0 20-Apr-2010 09:27 recup_dir.17
dr-xr-xr-x     0     0         0 20-Apr-2010 09:27 recup_dir.18
dr-xr-xr-x     0     0         0 20-Apr-2010 09:27 recup_dir.19
dr-xr-xr-x     0     0         0 20-Apr-2010 11:33 recup_dir.2
                                                   Next
Use Right arrow to change directory, c to copy,
    q to quit

     Linux                63746   0  1 76820 254 60  210049872
Directory /

drwxr-xr-x     0     0      4096 10-Mar-2010 13:16 .
drwxr-xr-x     0     0      4096 10-Mar-2010 13:16 ..
drwx------     0     0     16384 10-Mar-2010 13:16 lost+found


Use Right arrow to change directory, c to copy,
    h to hide deleted files, q to quit

     Linux                76821   0  1 84469 254 62  122881184 [rdiff-backup]
Directory /

drwxrwxrwx  1000  1000      4096  9-Apr-2010 19:08 .
drwxrwxrwx  1000  1000      4096  9-Apr-2010 19:08 ..
drwx-w--w-  1000  1000     16384  8-Apr-2010 19:47 lost+found
drwxr-xr-x  1000  1000     32768  9-Apr-2010 19:59 Sauvegarde avec Déja Dup 10.2
drwxr-xr-x  1000  1000      4096  9-Apr-2010 12:29 Sauvegarde avec Back in Time
drwxr-xr-x  1000  1000     32768  9-Apr-2010 19:59 Sauvegarde avec Déja Dup 


Use Right arrow to change directory, c to copy,
    h to hide deleted files, q to quit

Ouah ! Pour moi c'est ici que ca se passe :

     HPFS - NTFS              0   1  1 25495 254 63  409593177
Directory /

dr-xr-xr-x     0     0         0  9-Dec-2009 09:55 .
dr-xr-xr-x     0     0         0  9-Dec-2009 09:55 ..
dr-xr-xr-x     0     0         0 18-Dec-2009 15:11 copie  usb 16 GO
dr-xr-xr-x     0     0         0 18-Dec-2009 11:57 COPIE CLES 8GO bis
dr-xr-xr-x     0     0         0 15-Mar-2010 13:38 COPIE CLÉS 8 Go
dr-xr-xr-x     0     0         0  7-Dec-2009 08:29 COPIE COMPACT 1
dr-xr-xr-x     0     0         0 14-Dec-2009 17:56 COPIE F fig. N
dr-xr-xr-x     0     0         0 14-Dec-2009 18:01 COPIE G fig. N
dr-xr-xr-x     0     0         0  7-Dec-2009 08:27 COPIE GRIS
dr-xr-xr-x     0     0         0  7-Dec-2009 16:25 COPIE HP COMPACT
dr-xr-xr-x     0     0         0 26-Oct-2009 16:12 Musiques
dr-xr-xr-x     0     0         0 26-Oct-2009 16:10 RECYCLER
dr-xr-xr-x     0     0         0 22-Dec-2009 11:20 Start Downloader
dr-xr-xr-x     0     0         0  9-Dec-2009 09:53 System Volume Information
                                                   Next
Use Right arrow to change directory, c to copy,
    q to quit

A tout a l'heure.................

Comme le disais rmy c'est ici :
HPFS - NTFS 0 1 1 25495 254 63 409593177
Sauf nouvelle erreur de ma part.

post # 166

rmy a écrit :

Salut,
Le plus simple dans ton cas :
1/ recréer la partition NTFS avec testdisk, puis "write", puis corriger le BS avec le backup comme déjà vu
2/ Rebooter et monter cette partition nouvellement recréée.

mais je pense finalement que le plus gros bug dans cette affaire est une histoire de ... communication.
Mais surtout, je te conseille d'essayer l'option précédente (recréer la partition ntfs) puis de lancer un windows si tu en as un qui traine, de brancher ce disque avec le ntfs récupéré, et de faire un chkdsk /f sur cette partition.

post # 167

loreleil.747 a écrit :

Bonjour rmy,

J'avais maintenu testdisk en attente.

dim. 01 août 2010 12:38:30 CEST 


TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
P HPFS - NTFS              0   1  1 25495 254 63  409593177
D HPFS - NTFS              0   1  1 121600 254 63 1953520002
D Linux                25496   0  1 63745 254 61  614486248 [SAUVExt300Go]
D HPFS - NTFS          32589   0  1 59470 254 63  431859330
D Linux                63746   0  1 76820 254 60  210049872
D Linux                76821   0  1 84469 254 62  122881184 [rdiff-backup]





Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
NTFS found using backup sector!, 209 GB / 195 GiB

1/ recréer la partition NTFS avec testdisk, puis "write", puis corriger le BS avec le backup comme déjà vu

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63

     Partition                  Start        End    Size in sectors

 1 P HPFS - NTFS              0   1  1 25495 254 63  409593177

[  Quit  ]  [ Write  ]
                       Write partition structure to disk

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Write partition table, confirm ? (Y/N)

Yes .

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition                  Start        End    Size in sectors
 1 P HPFS - NTFS              0   1  1 25495 254 63  409593177

Boot sector
Status: Bad

Backup boot sector
Status: OK

Sectors are not identical.

A valid NTFS Boot sector must be present in order to access
any data; even if the partition is not bootable.

[Backup BS] .......... oui !

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Copy backup NTFS boot sector over boot sector, confirm ? (Y/N)

Yes.

Disk /dev/sdg - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition                  Start        End    Size in sectors
 1 P HPFS - NTFS              0   1  1 25495 254 63  409593177

Boot sector
Status: OK

Backup boot sector
Status: OK

Sectors are identical.

A valid NTFS Boot sector must be present in order to access
any data; even if the partition is not bootable.



[  Quit  ]  [  List  ]  [Rebuild BS]  [Repair MFT]  [  Dump  ]
                List directories and files, copy data from NTFS

dim. 01 août 2010 17:23:43 CEST 

TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


You will have to reboot for the change to take effect.



[Ok]

2/ Rebooter et monter cette partition nouvellement recréée.
C'est fait.

Mais surtout, je te conseille d'essayer l'option précédente (recréer la partition ntfs) puis de lancer un windows si tu en as un qui traine, de brancher ce disque avec le ntfs récupéré

Merci du conseille.
et de faire un chkdsk /f sur cette partition.
C'est en cours.

Si c'est résolu, c'est l'essentiel, mais je pense finalement que le plus gros bug dans cette affaire est une histoire de ... communication.
histoire de ... communication.
Certes, oui !
Fatigue et : loreleil, no stress, c'est bien de le dire, mais il faut le faire. Tu veux aller plus vite que la musique.

ps : Je le passerai en [ Résolu ] prochainement .....

Un grand merci à toi rmy.

post #168

rmy a écrit :

De rien, c'est un plaisir d'aider, et que chacun se rende compte que lorsque je propose mes services à prix libre, ce n'est pas pour rien
Mais en toute honnêteté et sincérité, je préfère (ma femme n'est pas d'accord, mais c'est comme ça, je ne me referai pas à 33 ans) aider quelqu'un gratuitement ici et ne pas avoir gagné d'argent ! Tu admets j'espère que tu aurais gagné en temps et en stress si je m'en étais occupé . Par contre, honnêtement, le résultat aurait probablement été le même au final.

post #169

loreleil.747 a écrit :

Bonjour,
J'en convient.
Je fais parti de ces " élus de la boulette " qui te sont grandement redevable .
A Ton retour de vacances, je te contacterai, cette fois pour un dd interne que je garde au chaud depuis environ 6 ans. Il se trouve qu'il n'est plus détecté(sous xp).
Ces jours ci, je tenterai de le passer en esclave sous ubuntu, puis en live cd en cas d'échec, et te fournir le maximum d'infos gérables.
Bien sur si tu en a le temps, dans quel cas, je te demanderai de bien vouloir m'indiquer les modalités d'envois, réceptions, et services par mp.
Merci à toi. !
Amicalement, loreleil.

post #170

rmy a écrit :

pas de problème. Je suis justement en train de finaliser mon site "pro". T uauras toutes les infos nécessaires là-bas. Je t'envoie de suite un mp pour prise de contact. Relance moi fin août, le temps de gérer le retour.

grand MERCI rmy. ! je t'en serre cinq.

Spawn600 · Le 18/08/2010, à 16:46

Bonjour a tous.
Après bien des recherches sur le net, je suis tomber sur ce topic et suivi le travail de rmy. Très gros travail accompli sur ces logiciels de récupération de données.
J'ai moi même un soucie sur deux disque dur et je demande votre l'aide.

Dans un 1er temps les deux dd sont crypter avec truecrypt, le dd est chiffrer entièrement donc une partition sur l'ensemble des dd.
Le disque a été brancher sur un pc équipe de Vista et depuis il n'est plus possible de m'ouvrir avec truecrypt, il me dit partition non truecrypt ou mdp incorrect.
Le mdp est bon c'est des fichiers images.
J'ai vu sur le site de testdisk que l'on pouvait récupérer des partitions truecrypt avec testdisk d'où mon interrogation, Est ce possible en sachant que je n'ai rien toucher sur les deux dd ?
Je suis sous win 7 x64 et passer plus tard a une partition dedier a Ubuntu mais en attendans je pourrais passer par un liveCD pour dépanner mes deux dd. Que pensez vous de mon problème.

D'avance merci

rmy · Le 18/08/2010, à 20:50

Peux-tu ouvrir un sujet spécifique et donner le lien ici, je m'y pencherai dès mon retour à la maison ce week-end. Ici, la connexion est digne du pigeon voyageur. Donne aussi plus de précisions sur ta situation actuelle : si j'ai bien compris tu es sous win seven et tu as créé deux disques chiffrés avec truecrypt dont les clés sont enregistrées sous formes de fichiers (dans les disques en question ?). Tu n'as actuellement pas d'ordi sous linux ou je n'ai pas bien compris ?
As-tu essayé de monter les disques en question depuis linux éventuellement ? Que donne le retour de testdisk sur chacun de ces disques ? N'hésites pas à répondre à ces questions directement dans le post spécifique que tu ouvres à ce sujet.

Spawn600 · Le 18/08/2010, à 23:45

Ok, merci rmy de ta réponse rapide, je pourrais donner de plus amples renseignements d'ici quelques jour. Je serais a la maison ce week end donc j'ouvre un fil et mets le lien sur celui ci si j'ai bien compris.
Pour l'info je n'ai jamais toucher a ubuntu juste essayer des liveCd pour utiliser photosrec.
Peut tu me dire si tu a déjà rencontrer des problèmes avec des partitions truecrypt et si la situation n'est pas trop compliquer pour un neophite.

Bonne nuit a demain

ps : les fichiers clé sont stocké a l'abri sur une clé USB.

Dernière modification par Spawn600 (Le 19/08/2010, à 09:30)

rmy · Le 19/08/2010, à 21:44

truecrypt non, j'utilise cryptsetup. Je ne peux t'en dire plus sur la complexité de ta situation sans aller un peu plus loin dans le diagnostic, on verra ça ce week-end. Toutefois, si tu es néophyte avec linux, ça sera peut-être un brin plus délicat. À moins que tes compétences en info soient suffisamment sérieuses pour que tu puisses t'adapter sans difficultés.

Quoi qu'il en soit, si tu ne comprends pas ce que je tenterai de te faire faire, demande plutôt que de faire une bêtise, et éventuellement jette un œil à ma signature si tu veux me contacter de manière "privée" pour que je m'en charge.

Spawn600 · Le 19/08/2010, à 22:29

Tombé dans le monde de l'informatique très tôt Grace a mon père, je pense bouloir et pouvoir apprendre beaucoup de cette expérience.
Je vais lire quelques post et tuto de Linux pour me familiariser avec lui et serais un peux plus près pour ce week end
merci a toi

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#201 Le 28/04/2010, à 09:09

Re : [Tuto] Bilan : comment récupérer des données perdues

#202 Le 28/04/2010, à 09:29

Re : [Tuto] Bilan : comment récupérer des données perdues

#203 Le 28/04/2010, à 11:11

Re : [Tuto] Bilan : comment récupérer des données perdues

#204 Le 28/04/2010, à 12:24

Re : [Tuto] Bilan : comment récupérer des données perdues

#205 Le 28/04/2010, à 12:27

Re : [Tuto] Bilan : comment récupérer des données perdues

#206 Le 28/04/2010, à 12:28

Re : [Tuto] Bilan : comment récupérer des données perdues

#207 Le 28/04/2010, à 23:06

Re : [Tuto] Bilan : comment récupérer des données perdues

#208 Le 28/04/2010, à 23:31

Re : [Tuto] Bilan : comment récupérer des données perdues

#209 Le 01/05/2010, à 19:48

Re : [Tuto] Bilan : comment récupérer des données perdues

#210 Le 02/05/2010, à 01:57

Re : [Tuto] Bilan : comment récupérer des données perdues

#211 Le 02/05/2010, à 13:53

Re : [Tuto] Bilan : comment récupérer des données perdues

#212 Le 03/05/2010, à 12:57

Re : [Tuto] Bilan : comment récupérer des données perdues

#213 Le 06/06/2010, à 22:44

Re : [Tuto] Bilan : comment récupérer des données perdues

#214 Le 07/06/2010, à 23:59

Re : [Tuto] Bilan : comment récupérer des données perdues

#215 Le 08/06/2010, à 07:33

Re : [Tuto] Bilan : comment récupérer des données perdues

#216 Le 08/06/2010, à 10:00

Re : [Tuto] Bilan : comment récupérer des données perdues

#217 Le 15/06/2010, à 23:59

Re : [Tuto] Bilan : comment récupérer des données perdues

#218 Le 16/06/2010, à 03:01

Re : [Tuto] Bilan : comment récupérer des données perdues

#219 Le 17/07/2010, à 22:31

Re : [Tuto] Bilan : comment récupérer des données perdues

#220 Le 04/08/2010, à 18:31

Re : [Tuto] Bilan : comment récupérer des données perdues

#221 Le 18/08/2010, à 16:46

Re : [Tuto] Bilan : comment récupérer des données perdues

#222 Le 18/08/2010, à 20:50

Re : [Tuto] Bilan : comment récupérer des données perdues

#223 Le 18/08/2010, à 23:45

Re : [Tuto] Bilan : comment récupérer des données perdues

#224 Le 19/08/2010, à 21:44

Re : [Tuto] Bilan : comment récupérer des données perdues

#225 Le 19/08/2010, à 22:29

Re : [Tuto] Bilan : comment récupérer des données perdues

Pied de page des forums