restauration d'image disque avec ddrescue fail

Ux · Le 09/09/2015, à 22:42

jamesbad000 a écrit :

Mais de ton coté peut-tu me donner le retour de (adapte pour utiliser la copie)
sudo fsck.ext4 -n /dev/sdb
Histoire de voir si la réaction est toujours la même.

Ca donne :

ux@gni:~$ sudo fsck.ext4 -n /media/ux/WD3TO/2to.dd 
[sudo] password for ux: 
e2fsck 1.42.9 (4-Feb-2014)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext4 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext4: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /media/ux/WD3TO/2to.dd

The superbloc could not be read or does not describe a valid ext2/ext3/ext4
système de fichiers.  If the périphérique is valid and it really contains an ext2/ext3/ext4
système de fichiers (and not swap or ufs or something else), then the superbloc
is corrupt, and you might try running e2fsck with an alternate superbloc:
    e2fsck -b 8193 <périphérique>
 or
    e2fsck -b 32768 <périphérique>

jamesbad000 a écrit :

Oui, ben faut pas trop rêver quand même... Tu a vraisemblablement écrasé une partie de données essentielle à la reconstitution de ce puzzle de 400 millions de pièces, alors il va pas suffire de presser un bouton pour récupérer quelque chose d'utile.

Oui c'est vrai pourtant il ne faut pas grand chose pour tout casser (et une bonne dose d’inattention aussi j'avoue...)

jamesbad000 · Le 10/09/2015, à 00:56

Pour le coup, la réaction est déjà plus conforme aux données que l'on vient de voir, que ce qui s'était passé dans ton post de ? de 2013 ! A oui quand même !
A croire qu'il c'est passé quelque chose entre temps. Tu peux donner ton emploi du temps exacte pour cette période :-)

Bon à ce stade, il va falloir que je réfléchisse longuement pour voir si je peux trouver une façon de faire mieux qu'un fsck brut de fonderie.
Mais en attendant, puisque on a une copie ça serait dommage de se priver de la foutre en l'air pour voir ce que ça donne (Quitte à devoir refaire l'image après si le résultat est trop désastreux)

Pour commencer tentons de déterminer l'emplacement des superblock de secours avec

sudo dumpe2fs /media/ux/WD3TO/2to.dd | grep superbloc

si ça ne donne rien, on fait une simulation de création du système de fichier. Qui va nous donner l'emplacement probable de ces super bloc (Sauf si tu as bidouillé des paramètres lors de la création)

sudo mke2fs -n /media/ux/WD3TO/2to.dd

La aussi le -n est à ne pas oublier

Dernière modification par jamesbad000 (Le 10/09/2015, à 02:03)

Bougron · Le 10/09/2015, à 08:47

Bonjour
Si tu connais le nom du fichier que tu veux retrouver, as-tu cherché s'il était encore présent pour une éventuelle utilisation par tesdisk ?
As-tu fais de nouveaux essais avec photorec? Si tu connais la famille de fichier auquel il appartient ( .doc .odt .log .html .exe etc....), je me propose de rechercher la bonne valeur du filtre.

Dernière modification par Bougron (Le 10/09/2015, à 08:49)

Ux · Le 10/09/2015, à 08:52

Haha, non il ne s'est rien passé entre temps, j'attendais juste le "bon" moment 4to de disque immobilisé depuis... un gros hic a chaque fois que je repense à ce disque... ça me pesait un peu ! même si avec le temps, on apprends la relative importance des données puisque j'oublie peu à peu le contenu du disque...

La premier commande ne donne rien

dumpe2fs: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /media/ux/WD3TO/2to.dd
Impossible de trouver un superbloc de système de fichiers valide.

La deuxieme donne :

/media/ux/WD3TO/2to.dd n'est pas un périphérique spécial en mode bloc.
Procéder malgré tout ? (o,n) o
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
« Stride » = 0 blocs, « Stripe width » = 0 blocs
122101760 i-noeuds, 488378646 blocs
24418932 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=4294967296
14905 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

concernant bousiller la copie ok mais je dois dire que mon disque actuel /sdb est une restauration de cette image. J’espère que refaire une image donnera bien la même chose (autrement dit image=clone ?)

Ux · Le 10/09/2015, à 11:21

Bougron a écrit :

Bonjour
Si tu connais le nom du fichier que tu veux retrouver, as-tu cherché s'il était encore présent pour une éventuelle utilisation par tesdisk ?
As-tu fais de nouveaux essais avec photorec? Si tu connais la famille de fichier auquel il appartient ( .doc .odt .log .html .exe etc....), je me propose de rechercher la bonne valeur du filtre.

Bonjour,

En fait non je ne recherche pas un fichier en particulier mais plutot a récupérer un bon TO de musique/phot/code etc qui ont évidemment une valeur personnelle. Et puis dans testdisk je ne liste aucun fichier (cf. postes précédents).
Je n'ai pas encore fait de nouveau essai avec photorec, j'y viendrai en dernier, car trier 2to de fichiers brut à la main ce n'est pas humain !!! (quoique avec un bon turc mécanique...)
J'attends de voir ce que mister jamesbad000 peut me proposer avant ça (ou tout autres personne d'ailleurs hein ^^, moi ça me dépasse un peu à ce niveau la !)

A+

jamesbad000 · Le 10/09/2015, à 11:26

Ux a écrit :

concernant bousiller la copie ok smile mais je dois dire que mon disque actuel /sdb est une restauration de cette image. J’espère que refaire une image donnera bien la même chose (autrement dit image=clone ?)

Oui en principe la copie avec dd ou ddrescue est identique. Pour autant je suggérais de travailler sur la copie plutôt que l'original. Sauf que j'ai cru que sdb était l'original.
Bref du coup fait la suite des manip sur sdb.
Enfin cela soulève une nouvelle question: Ton image disque elle est intègre ? Je veux dire par là que dans ton post de 2013 on voit que tu lui as peut être fait subir quelques outrages avec gpart. Est-ce que tu as refait l'image après ça ?

Quoiqu'il en soit tentons prudemment de voir si la liste des superblock de secours est exploitable en commençant par le dernier de la liste

sudo dumpe2fs -h -o superblock=214990848 /dev/sdb

Ux · Le 10/09/2015, à 12:02

Ok je teste ça ce soir quand je serai devant ma machine.

Et oui mon image est intègre car je l'ai faite avant toute manip (en suivant les recommandations dans le post de référence de RMY à l'époque, post fermé depuis )

Dernière modification par Ux (Le 10/09/2015, à 12:03)

Bougron · Le 10/09/2015, à 15:37

Ux a écrit :

Alors voila le contenu de la partition XFS4 (listée plus haut) quand je fais le deepsearch en none, comme suggéré par Bougron.

P ext4                     0   0  1 243201  80 63 3907029168 [Data]
 P FAT32                    0   0  1 243201  80 63 3907029168
 P FAT32                    0   0  7 243201  81  6 3907029168
 P HFS+                 13381  12 13 13432   9  6     819120
 P HFS+                 13381  56 31 13432  53 24     819120
 P HFS+                 13381 250 13 13432 247  6     819120
 P HFS+                 13381 252 31 13432 249 24     819120
 P HFS+                 13382  27 54 13433  24 47     819120
 P HFS+                 13382  27 55 13433  24 48     819120
 P HFS+                 13432   9  3 13483   5 59     819120
 P HFS+                 13432  53 21 13483  50 14     819120
 P HFS+                 13432 247  3 13483 243 59     819120
 P HFS+                 13432 249 21 13483 246 14     819120
 P HFS+                 13433  24 44 13484  21 37     819120
 P HFS+                 13433  24 45 13484  21 38     819120
M-4^NAmM-{      BD>A]   57710 199 12 90217 177 60  522223618 [M-4^NAmM-{        BD>AJ^L^B+
 P HFS                  57710 199 15 90217 177 63  522223618 [~[^NAmM-{ BD>AJ^L^B+~E~[^NAmM-{   QD>A]
 P HFS                  57710 199 46 90217 178 31  522223618 [P^OAmM-{  BD>AJ^L^B+ ^OAmM-{      BD>A]
 P HFS                  57710 199 63 90217 178 48  522223618 [^L^B+M-%^OAmM-{   BD>AJ^L^B+M-m^OAmM-{    ]
 P HFS                  65668 167  7 230297  86 35 2644759811 []M-3imM-*M-pM-.mM-n M-0^O~?~?^X~_ ~[~V~@^U of %lx)
]  ]ramFS               79353 162 35 79494  18 12    2256071 [^FM-aq M-%:-[
]  ]ramFS               79353 162 36 79494  18 13    2256071 [^FM-aq M-%:-[
M-4^NAmM-{      BD>A]   90217 177 57 122724 156 42  522223618 [M-4^NAmM-{       BD>AJ^L^B+
 P HFS                  90217 177 60 122724 156 45  522223618 [~[^NAmM-{        BD>AJ^L^B+~E~[^NAmM-{   QD>A]
 P HFS                  90217 178 28 122724 157 13  522223618 [P^OAmM-{ BD>AJ^L^B+ ^OAmM-{      BD>A]
 P HFS                  90217 178 45 122724 157 30  522223618 [^L^B+M-%^OAmM-{  BD>AJ^L^B+M-m^OAmM-{    ]
 P FAT12                96736 241 26 96737   0 39        896
 P FAT12                110242 232 15 110242 246 28        896
 P NTFS                 111872 149 21 113176 148 20   20948697
 P NTFS                 111879 245  6 113183 244  5   20948697
 P NTFS                 113176 148 20 114480 147 19   20948697
 P NTFS                 113183 244  5 114487 243  4   20948697
 P FAT12                113276  25 17 113277  99 28      20739 [NO NAME]
 P FAT16                113276  25 21 113290   5 54     223684 [NO NAME]
M-4^NAmM-{      BD>A of %lx)
 P HFS                  140403 212 23 172910 191  8  522223618 [~[^NAmM-{       BD>AJ^L^B+~E~[^NAmM-{   QD>A of %lx)
 P HFS                  140403 212 54 172910 191 39  522223618 [P^OAmM-{        BD>AJ^L^B+ ^OAmM-{      BD>A of %lx)
 P HFS                  140403 213  8 172910 191 56  522223618 [^L^B+M-%^OAmM-{ BD>AJ^L^B+M-m^OAmM-{     of %lx)
 P HFS                  140664  16 63 173170 250 48  522223618 [^OAmM-{ BD>AJ^L^B+}^OAmM-{      BD>A of %lx)
 P CramFS               151427 109 20 151789  33 63    5810786 [^Z/M-XM-' ^BM-B<-`$i]
 P CramFS               151427 109 21 151789  34  1    5810786 [^Z/M-XM-' ^BM-B<-`$i]
 P CramFS               168895   1 45 169417  16 31    8386862 [M-"~]^G~C. 
 P CramFS               168895   1 46 169417  16 32    8386862 [M-"~]^G~C. 
M-4^NAmM-{      BD>A of %lx)
 P HFS                  172910 191  5 205417 169 53  522223618 [~[^NAmM-{       BD>AJ^L^B+~E~[^NAmM-{   QD>A of %lx)
 P HFS                  172910 191 36 205417 170 21  522223618 [P^OAmM-{        BD>AJ^L^B+ ^OAmM-{      BD>A of %lx)
 P HFS                  172910 191 53 205417 170 38  522223618 [^L^B+M-%^OAmM-{ BD>AJ^L^B+M-m^OAmM-{     of %lx)
 P HFS                  173170 250 45 205677 229 30  522223618 [^OAmM-{ BD>AJ^L^B+}^OAmM-{      BD>A of %lx)
 P NTFS                 203509  36 27 203509 134 26       6174
 P NTFS                 203844   9 62 203844 107 61       6174 [Boot]
 P FAT12                203844 109 50 203845 183 61      20739 [NO NAME]
 P NTFS                 204494 166 40 204495   9 39       6174
 P NTFS                 204495   9 39 204495 107 38       6174 [Boot]
>P FAT12                204495 109 27 204496 183 38      20739 [NO NAME]
 P FAT12                204495 109 27 204496 183 38      20739 [NO NAME]
 P NTFS                 211497  24 26 224550  23 25  209696382
 P NTFS                 211505 253 52 224558 252 51  209696382
 P NTFS                 216296 150 27 220211 149 26   62894412
 P NTFS                 216305  71 14 220220  70 13   62894412
 P CramFS               219302 114 55 219824 129 41    8386862 [M-"~]^G~C. 
 P CramFS               219302 114 56 219824 129 42    8386862 [M-"~]^G~C. 
 P NTFS                 220211 149 26 224126 148 25   62894412
 P NTFS                 220220  70 13 224135  69 12   62894412
 P FAT12                220318 194 16 220320  13 27      20739 [NO NAME]
 P FAT16                220318 194 20 220332 174 53     223684 [NO NAME]
 P NTFS                 220325   6 14 224240   5 13   62894412
 P NTFS                 220333 182  1 224248 180 63   62894412
 P NTFS                 224240   5 13 228155   4 12   62894412
 P NTFS                 224248 180 63 228163 179 62   62894412
 P FAT12                224458 180 14 224459 254 25      20739 [NO NAME]
 P FAT16                224458 180 18 224472 160 51     223684 [NO NAME]
 P NTFS                 224550  23 25 237603  22 24  209696382
 P NTFS                 224558 252 51 237611 251 50  209696382
 P FAT12                224870  45 11 224871 119 22      20739 [NO NAME]
 P FAT16                224870  45 15 224884  25 48     223684 [NO NAME]
 P NTFS                 224995 120 39 228246   2 61   52219904
 P NTFS                 224995 185 39 228246  67 61   52219904
 P NTFS                 226195 231  6 229446 113 28   52219904
 P HFS+                 226635  16 57 226766  91  8    2109192
 P CramFS               226653 115 47 226738 218 16    1371984 [GWM-9M-$ث݊M-= b~^dS 
 P CramFS               226653 115 48 226738 218 17    1371984 [GWM-9M-$ث݊M-= b~^dS 
 P NTFS                 226689 146 35 229940  28 57   52219904
 P HFS+                 226766  91  5 226897 165 19    2109192
 P HFS+                 226782 172  6 226913 246 20    2109192
 P HFS+                 226913 246 17 227045  65 31    2109192
 P NTFS                 228232  94 40 228245  30 26     204800
 P NTFS                 228232  99  5 228245  34 54     204800
 P NTFS                 228232 159 40 228245  95 26     204800
 P NTFS                 228245  30 26 228257 221 12     204800
 P NTFS                 228245  34 54 228257 225 40     204800
 P NTFS                 228245  95 26 228258  31 12     204800
 P FAT12                228245 246 45 228246  37 26       2880 [NO NAME]
 P NTFS                 228246   2 61 231496 140 20   52219904
 P NTFS                 228246  67 61 231496 205 20   52219904
 P NTFS                 228422  88 14 228422 186 13       6174
 P NTFS                 228422 186 13 228423  29 12       6174 [Boot]
 P NTFS                 228422 219  1 228423  61 63       6174
 P NTFS                 228423  61 63 228423 159 62       6174 [Boot]
 P FAT12                228958 205 27 228960  24 38      20739 [NO NAME]
 P NTFS                 229376 107  7 229376 205  6       6174
 P NTFS                 229376 205  6 229377  48  5       6174
 P NTFS                 229446 113 28 232696 250 50   52219904
>P NTFS                 229940  28 57 233190 166 16   52219904

Autant dire il y a du monde
Quand j'essaye de lister les fichiers de la premiere (qui ressemble bien a ma partition perdue!) j'ai ça

 P ext4                     0   0  1 243201  80 63 3907029168 [Data]
Directory /

No file found, filesystem may be damaged.

Je suis en train de voir sur les autres...

edit: c'est pareil pour toutes les autres

Tu n'as pas tout à fait compris lorsque je t'ai fait vider le début du disque. il montrait clairement qui'il n'y avait que des zéros dans le débu du disque
Pour faire tes recherches commences à partir de
Linux 121422 191 50 364624 17 49 3907029168 [Data]

et à partir de cette position, on ne trouve plus aucune structure ext4!

Mais continues la piste de réparation sur le disque qui est maintenant copie du fichier de sauvegarde.

Dernière modification par Bougron (Le 10/09/2015, à 17:07)

Bougron · Le 10/09/2015, à 17:01

Ux a écrit :

...
Je recherche à récupérer un bon TO de musique/phot/code etc qui ont évidemment une valeur personnelle. Et puis dans testdisk je ne liste aucun fichier (cf. postes précédents).
Je n'ai pas encore fait de nouveau essai avec photorec, j'y viendrai en dernier, car trier 2to de fichiers brut à la main ce n'est pas humain !!! (quoique avec un bon turc mécanique...)
J'attends de voir ce que mister jamesbad000 peut me proposer avant ça ...
A+

On est d'accord sur le fait que la réparation des structures serait nettement mieux...
Cependant, tu pourrais commencer à regarder ce que cela peut récupérer.
Je ne comprends pas "trier 2 To",,,, Il n'y aura que des fichiers à renommer!!!!
Vu ce que tu recherches, j 'ai identifié trois types de nature de fichiers à positionner avant de lancer la recherche
bmp jpg mp3

attention, après avoir désélectionné la totalité des fichiers et positionné les tiens, n'oublies pas de sauver ta sélection par la commande b
Tu pourrais lancer et au moins avoir une idée de ce qui va être retrouvé en quantité de fichiers plutôt qu'en volume.

Pour info: Je viens de découvrir que photorec pouvait aussi ne retrouver que les "super-blocs".

Dernière modification par Bougron (Le 10/09/2015, à 17:05)

Ux · Le 10/09/2015, à 22:40

Voila pour le dernier superbloc :

ux@gni:~$ sudo dumpe2fs -h -o superblock=214990848 /dev/sdb
[sudo] password for ux: 
dumpe2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   Data
Last mounted on:          <not available>
Filesystem UUID:          dbab2b6e-7e51-43f2-9730-e96f3384c0df
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378646
Reserved block count:     24418932
Free blocks:              480665227
Free inodes:              122101749
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              1
RAID stripe width:        1
Flex block group size:    16
Filesystem created:       Fri Jul 15 19:52:30 2011
Last mount time:          n/a
Last write time:          Fri Jul 15 19:52:45 2011
Mount count:              0
Maximum mount count:      20
Last checked:             Fri Jul 15 19:52:30 2011
Check interval:           15552000 (6 months)
Next check after:         Wed Jan 11 18:52:30 2012
Lifetime writes:          144 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      1c614f70-d6f1-4f24-8fff-858c9486ae57
Journal backup:           inode blocks
Journal superblock magic number invalid!

Merci pour tes précisions Bourgon, ce que je voulais dire par la, c'est que même renommer une certaine quantité de fichier (on parle de milliers de fichiers) c'est pas évident pour les mp3 je me doute qu'il doit bien exister des soft qui font ca automatiquement... pour le reste c'est pas evident !

Bonne soirée

Bougron · Le 10/09/2015, à 23:01

Ux a écrit :

pour les mp3 je me doute qu'il doit bien exister des soft qui font ça automatiquement...
Bonne soirée

A condition que cela soit de la musique légalement déposée il y a effectivement des logiciels qui savent reconnaître ce que les "auteurs" ont fait (Dans ce cas, tu devrais pouvoir re-télécharger). Mais si ce sont les premières paroles de tes enfants (données personnelles) j'en doute.

et pour les photos, il y a picasa qui dit savoir reconnaître les personnages. et donc regrouper.. tes enfants....

Dernière modification par Bougron (Le 10/09/2015, à 23:06)

jamesbad000 · Le 11/09/2015, à 13:55

Ok. Avec ce superblock on va pouvoir avancer.

Je suis en train de faire des essais sur une image de partition ext4 de 10Go reformaté en fat

avec un fsck "brut", sur 101657 fichiers et 14065 répertoires je récupère 84941 fichiers et 11972 répertoires. Ce qui n'est pas si mal.
Mais je vais vérifier la qualité des données récupérées et voir si on ne peut pas affiner un peu (par exemple trouver une façon de contrer l'élimination de certains fichiers qui pourraient être récupérables...)

edit : à l'occasion renvoi le retour de

uname -a
lsb_release -d

Car arrivé à ce niveau, il vaut mieux savoir précisément avec quoi on travail.

edit 2: Donne aussi le retour de (avec le disque connecté)

sudo lsblk --o size -f
ls -l /dev/disk/by-id/

Dernière modification par jamesbad000 (Le 11/09/2015, à 16:42)

jamesbad000 · Le 13/09/2015, à 21:06

Hello. Bon je ne sais pas s'il y a abandon du problème ou si tu attendais que j'en dise plus. Mais moi j'ai fait à peu près le tour...

La prochaine chose qui serait à faire avant de passer au fsck proprement dit c'est :
1 - vérifier le /dev/sdX (peut changer d'une fois sur l'autre suite à reboot ou introduction d'un autre dev sur USB, et ce n'est pas la peine d'aller bousiller un autre disque !!!) avec la commande lsblk indiquée dans le post précédent. Et adapter les commandes ci-dessous en conséquence. Respirer, revérifier !!

2 :

# efface la signature fat32 ainsi que début fat. ATTENTION au /dev et attention au count !!!
sudo dd if=/dev/zero of=/dev/sdX  count=36 conv=notrunc

EDIT : Ajouté "conv=notrunc" pour le cas ou cette commande serait appliquée sur un fichier image. (Autrement commence par remettre l'image à une taille de 0 octets)

# cherche les 1ers octets non initialisés
sudo hexdump  /dev/sdX | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'

# liste les descripteurs de groupes 15&16
sudo dumpe2fs -o superblock=214990848 /dev/sdX |  grep -E  "^(Groupe| Bitmap| Table)" | head -n $((3*17)) | tail -n 6

Avec le résultat des 2 dernières commandes, on pourra identifier la liste des fichiers récupérés qui sont certainement en mauvais état du fait qu'ils utilisent des blocs de données situés dans la zone du disque initialisée par le formatage. (j'en ai eu plus de 500 dans mon test... Mais il peut y avoir une très très grande variabilité sur les ratio que j'ai obtenu par rapport à ta propre situation)

3 - ensuite la réparation proprement dite (ATTENTION au /dev !!!) :

sudo fsck.ext4  -yf -b 214990848 /dev/sdX

Selon que l'initialisation de la fat a été plus ou moins loin, il est possible que tu ne retrouve aucun fichier à la racine, et que tout soit dans "lost+found"

Quoiqu'il en soit, je te déconseille fortement de modifier quoi que ce soit, contente toi de recopier ce qui t'intéresse sur un autre disque. (ou mieux, attend qu'on ait pu obtenir la liste des fichiers répertoires foireux)

Dernière modification par jamesbad000 (Le 15/09/2015, à 14:04)

Ux · Le 14/09/2015, à 12:42

Salut James, et Merci beaucoup pour tes messages. Je n'abandonne pas, mais j'ai juste du passé le we sans machine.

Si je comprends bien fsck serait capable de retrouver la structure des fichiers avec les superblocs ?! Si ca marche vraiment chez moi ce serait super ! Tu me redonnes espoir

Je vais essayer rapidement, sans faire de bêtises, et te donne des retours.

Sinon, concernant ma config :

ux@gni:~$ uname -a
Linux gni 3.13.0-63-generic #103-Ubuntu SMP Fri Aug 14 21:42:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
ux@gni:~$ lsb_release -d
Description:	Ubuntu 14.04.3 LTS

 SIZE NAME   FSTYPE LABEL MOUNTPOINT
119,2G sda                 
  1,9G ├─sda1              
 46,6G ├─sda2 ext4         /
  7,5G ├─sda3 swap         [SWAP]
 63,4G └─sda4 ext4         /home
  1,8T sdb    vfat         
  2,7T sdc                 
  2,7T └─sdc1 ext4   WD3TO 
 1024M sr0               

ls -al /dev/sdb 
brw-rw---- 1 root disk 8, 16 sept. 14 12:31 /dev/sdb

A bientot !

Dernière modification par Ux (Le 14/09/2015, à 12:43)

Ux · Le 14/09/2015, à 13:08

Voila ce que j'ai pour les commandes pre-réparation, j'ai raté quelque chose ?

ux@gni:~$ sudo dd if=/dev/zero of=/dev/sdb count=36 
[sudo] password for ux: 
36+0 enregistrements lus
36+0 enregistrements écrits
18432 octets (18 kB) copiés, 0,00119218 s, 15,5 MB/s

ux@gni:~$ sudo hexdump  /dev/sdb | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'
1d18c000 fff8 0fff ffff 0fff fff8 0fff 0000 0000
29754000 d206 83f2 7f15 798a 71de fdca eb75 0fb6
29754010 cb95 5935 577f f9b6 0275 9394 74b5 883a
29754020 8a91 ffcd 8a89 fa63 840c 4c2b b5df f7ff
29754030 40fa 6dd5 28d6 6772 cda8 2832 708f 131f
29754040 be8f cbd7 b26f 55da 86ec 5cef 7faa acb7
29754050 447f b10b ff66 21ad 7a2a 6a1e 68a4 a320
29754060 0f28 a8d2 1858 3fa4 7955 9040 bb58 842a
29754070 a52b ab60 b7d6 4497 aee2 5712 445a 4002
29754080 c4de 59f8 7c2e 8841 6529 1117 da2e 7ab5
29754090 98b7 97b4 06eb 795d 1d9d b837 1d0c ed33
297540a0 4805 62fd 299e ac7a 0909 9ada 4b39 1409
297540b0 bd37 9ac0 9c85 d066 a229 3e90 f1a0 eab4
297540c0 d84a 1763 1abc 5ca4 fe3c b25e b6da b6d6
297540d0 6aac 8661 e55f 8577 9695 3ba7 b75c cbcb
297540e0 ebbf a9a5 8680 e4cc 9c04 42cc 36f0 2ed9
297540f0 c863 d8b9 d084 06a1 a431 764a 9e8c ca5f
29754100 f8f7 6bb4 ca20 7e82 a35e a7d1 aa2b 298a
29754110 7103 c06c 1e2c 800c 9a4a 45bc 4ed1 e5e1
29754120 627f 8015 0f9f f8c3 0658 eacc ada6 d9ea
29754130 8846 9ecc 7945 e3d0 32e1 4a8a 3b0f c576
29754140 47a1 7325 aa53 0744 a7f6 c9cf d97c 1962
29754150 47c3 a78d 662c 63f3 b079 bf26 652b 2e1f
29754160 a2c5 afc4 15b6 d4e4 80fe 3ff1 c6fb 7f77
29754170 068b 968c 1394 c298 7e9d 0d64 5bf2 7436
29754180 4491 0a06 d3e7 5b19 f5b6 f41c 86b6 195c
29754190 229f 68c2 5a05 9bde e8a1 7d66 990b 2d2a
297541a0 3424 5815 139a b4c0 a40d 31a9 867f 93d9
297541b0 2910 13d0 890d a70c 3797 7566 620e 66f0
297541c0 3c7d 45e4 a148 884c 1043 14a1 5547 4e34

ux@gni:~$ sudo dumpe2fs -o superblock=214990848 /dev/sdb |  grep -E  "^(Groupe| Bitmap| Table)" | head -n $((3*17)) | tail -n 6
dumpe2fs 1.42.9 (4-Feb-2014)
Journal superblock magic number invalid!

Dernière modification par Ux (Le 14/09/2015, à 13:09)

jamesbad000 · Le 14/09/2015, à 13:48

Hello.

Bon tu es sur le même niveau de version/kernel que moi. Ce qui devrait éviter pas mal de surprises...

Par contre ça, ça ne va pas.

Ux a écrit :

ux@gni:~$ sudo dumpe2fs -o superblock=214990848 /dev/sdb |  grep -E  "^(Groupe| Bitmap| Table)" | head -n $((3*17)) | tail -n 6
dumpe2fs 1.42.9 (4-Feb-2014)
Journal superblock magic number invalid!

Le filtrage avec grep a foiré probablement parce que tu es sur une installation anglophone.
Tentons une variante compatible franco/anglaise

sudo dumpe2fs -o superblock=214990848 /dev/sdb |  grep -E -i  "^(Group|\s+\w*\s*Bitmap|\s+\w*\s*Table)" | head -n $((3*17)) | tail -n 6

Dernière modification par jamesbad000 (Le 14/09/2015, à 18:07)

jamesbad000 · Le 14/09/2015, à 13:56

Si ce n'est pas trop tard, attend avant de lancer le fsck. Je viens de voir qu'il faudra aussi effacer la fat mirroir (ce n'est pas catastrophique, mais ça peut tout de même améliorer un peu la qualité de la récup)

La je vais m'absenter. Reprise des "hostilités" ce soir...

jamesbad000 · Le 14/09/2015, à 18:32

Bien, après vérification. La première ligne trouvée par la recherche hexdump correspond bien à la position de début de la fat miroir. On va donc l'effacer afin d'éviter que fsck considère cela comme indiquant la position de quelque chose à réparer (modifier)...

sudo dd  if=/dev/zero of=/dev/sdX bs=1 count=16 seek=$((0x1d18c000))  conv=notrunc

(toujours bien s'assurer du /dev/sdX et qu'aucun paramètre ne manque ou n'est altéré sur cette commande !!)

EDIT : Ajouté "conv=notrunc" pour le cas ou cette commande serait appliquée sur un fichier image. (Autrement commence par remettre l'image à une taille de 0 octets)

Par ailleurs le résultat du hexdump permet de déduire que tu n'a initialisé "que" 700 Mo (Alors que la fat + sont backup auraient du couvrir pratiquement 1 Go si l'opération de formatage avait été à son terme)

D'ailleurs, j'ai assez d'info pour extraire la liste des fichiers qui seront très probablement endommagés à l'issue de la réparation.

# icheck -- List les inodes pointant sur la liste de blocs écrasés par le formatage
(tu copie/colle tout ce bloc de ligne en une fois dans le terminal

rm ~/sdb.delblocks  ; 
bMax=169811;
for ((b=8865; b<$bMax; )); do 
  echo -en "$b\r"; 
  b2=$b;
  b3=$(($b+1000));
  bList="";
  for ((; b<$b3; b++)); do
    bList="$bList $b";
    if (($b==$bMax)); then break; fi;
  done;
  sudo debugfs -s 214990848 -b 4096 -R "icheck $bList" /dev/sdb 2>/dev/null | sed -re '/[0-9]+\s+[0-9]+/!d' >> ~/sdb.delblocks ; 
done;

Puis pour finir (la aussi, copier/coller l'intégralité en une seul fois)
-- ncheck - liste les fichiers correspondant à la liste de inodes pointant sur des block intialisés

nodes=$(sed -re 's:[0-9]+\s+([0-9]+):\1:' ~/sdb.delblocks  | sort | uniq); debugfs -s 214990848 -b 4096 -R "ncheck $(echo $nodes)" /dev/sdb > ~\sdb.badFiles; head ~\sdb.badFiles;

la liste de fichier foireux se trouvera dans sdb.badFiles dans ton répertoire perso.

Dernière modification par jamesbad000 (Le 15/09/2015, à 14:05)

Ux · Le 15/09/2015, à 09:51

Bonjour,

C'est super Jamesbad tu es un As, j'ai bien réussi a récupérer une grande grande partie de mes donnée avec le fsck !!!

Mais me sentant pousser des ailes, j'ai tout cassé...

Je m'explique : ayant fait la récupération fsck avant de recuperer la liste des fichiers non valides comme tu le proposes, je me suis dit que j'allais le faire avec mon image du disque faite avec ddrescue.
Sauf qu'en faisant

sudo dd  if=/dev/zero of=/media/ux/WD3TO/2to.dd bs=1 count=16 seek=$((0x1d18c000))

j'ai écrasé mon image originale, et je ne m'en suis pas rendu compte.
J'ai adapté le script bash pour mon image 2to.dd, mais je n'ai eu aucun fichier dans ~/sdb.delblock

Du coup, je me suis dis que j'allais refaire la procedure entiere, que j'allais restaure mon image sur /sdb . Grosse erreur, la restauration s'est arrêtée au bout de 400mo, la nouvelle taille de mon image .dd.

Voila ou j'en suis, mon image disque 2to.dd qui ne contient en fait le contenu de /dev/zero
et mon disque /dev/sdb qui contient la restauration ce cette image...

Bon je sais, j'ai fais le boulet, mais rassures moi quand meme James, le fsck peut marcher de nouveau ?! (je n'ai rien touché depuis...)

Bougron · Le 15/09/2015, à 12:06

jamesbad000 a écrit :

Bien, après vérification. La première ligne trouvée par la recherche hexdump correspond bien à la position de début de la fat miroir. On va donc l'effacer afin d'éviter que fsck considère cela comme indiquant la position de quelque chose à réparer (modifier)...
sudo dd  if=/dev/zero of=/dev/sdX bs=1 count=16 seek=$((0x1d18c000))
(toujours bien s'assurer du /dev/sdX et qu'aucun paramètre ne manque ou n'est altéré sur cette commande !!)
Par ailleurs le résultat du hexdump permet de déduire que tu n'a initialisé "que" 700 Mo (Alors que la fat + sont backup auraient du couvrir pratiquement 1 Go si l'opération de formatage avait été à son terme)
D'ailleurs, j'ai assez d'info pour extraire la liste des fichiers qui seront très probablement endommagés à l'issue de la réparation.
# icheck -- List les inodes pointant sur la liste de blocs écrasés par le formatage
(tu copie/colle tout ce bloc de ligne en une fois dans le terminal
rm ~/sdb.delblocks  ; 
bMax=169811;
for ((b=8865; b<$bMax; )); do 
  echo -en "$b\r"; 
  b2=$b;
  b3=$(($b+1000));
  bList="";
  for ((; b<$b3; b++)); do
    bList="$bList $b";
    if (($b==$bMax)); then break; fi;
  done;
  sudo debugfs -s 214990848 -b 4096 -R "icheck $bList" /dev/sdb 2>/dev/null | sed -re '/[0-9]+\s+[0-9]+/!d' >> ~/sdb.delblocks ; 
done;
Puis pour finir (la aussi, copier/coller l'intégralité en une seul fois)
-- ncheck - liste les fichiers correspondant à la liste de inodes pointant sur des block intialisés
nodes=$(sed -re 's:[0-9]+\s+([0-9]+):\1:' ~/sdb.delblocks  | sort | uniq); debugfs -s 214990848 -b 4096 -R "ncheck $(echo $nodes)" /dev/sdb > ~\sdb.badFiles; head ~\sdb.badFiles;
la liste de fichier foireux se trouvera dans sdb.badFiles dans ton répertoire perso.

Je dis 'chapeau' pour ce que tu fais.

Dernière modification par Bougron (Le 15/09/2015, à 13:32)

jamesbad000 · Le 15/09/2015, à 13:27

Ah oui évidemment tu as transgressé la règle absolue de ne pas toucher à l'original.
Et en plus tu ne donne pas le retour des commandes que tu as passé dans le terminal. (Si tu l'a toujours met tout en bloc. Je ferais le tri)

Ceci dit j'ai moi aussi une leçon à tirer de ça. Car si j'avais laissé le conv=notrunc, qui bien qu'inutile sur un périphérique, ne dérangeait en rien. Ton image serait encore là. (je vais corriger pour éviter que ce fil serve de mauvais exemple)

Bon si je comprend bien ce que tu as fais, ça ne devrait pas être si grave. Puisque tu as écrasé ce qui l'avait déjà été. Encore que le fsck a pu dupliquer des données dans cette partie s'il y avait des chevauchement de fichier. Mais il y a quand même de bonne chance que ça ne concerne que des données qui auraient été inexploitables.

Maintenant la prudence voudrait que tu refasse ton image avant de recommencer à jouer...

Avant tu peux quand même faire ça que je vois s'il nous reste quelque chose sur le disque. (ca ne fait que lire !)
# cherche les 1ers octets non initialisés

sudo hexdump  /dev/sdX | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'

Dernière modification par jamesbad000 (Le 15/09/2015, à 13:52)

jamesbad000 · Le 15/09/2015, à 13:41

Bougron a écrit :

Je dis 'chapeau' pour ce que tu fais.

C'est un peu prématuré vu le résultat. C'est sur qu'avec ce cas, je viens de faire de belles avancées dans ma compréhension de l'ext et de la fat.
Mais je m'en serais tenu à un fsck avec le superblock de secours et l'affaire serait bouclée. Avec pas forcément moins de fichiers valides récupérés... (Difficile d'avoir des certitudes sur ce dernier point)

Dernière modification par jamesbad000 (Le 15/09/2015, à 13:54)

Ux · Le 15/09/2015, à 20:49

Je vais commencer par refaire une image du disque oui mais pour l'instant au boot je suis obligé de le debrancher car le pc tente de booter dessus par default... bizarre.
edit : c'est bon je fais l'image, je reviens... (après 2to de copie)
ps: je n'ai plus les sorties désolé James...

Dernière modification par Ux (Le 15/09/2015, à 21:57)

Ux · Le 16/09/2015, à 22:12

Hello James, voici ce que donne la recherche

# cherche les 1ers octets non initialisés

ux@gni:~$ sudo hexdump  /dev/sdb | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'
0000000 58eb 6d90 646b 736f 7366 0000 2002 0020
0000010 0002 0000 f800 0000 003f 00ff 0000 0000
0000020 88b0 e8e0 8c40 000e 0000 0000 0002 0000
0000030 0001 0006 0000 0000 0000 0000 0000 0000
0000040 0000 7629 6a7b 206a 2020 2020 2020 2020
0000050 2020 4146 3354 2032 2020 1f0e 77be ac7c
0000060 c022 0b74 b456 bb0e 0007 10cd eb5e 32f0
0000070 cde4 cd16 eb19 54fe 6968 2073 7369 6e20
0000080 746f 6120 6220 6f6f 6174 6c62 2065 6964
0000090 6b73 202e 5020 656c 7361 2065 6e69 6573
00000a0 7472 6120 6220 6f6f 6174 6c62 2065 6c66
00000b0 706f 7970 6120 646e 0a0d 7270 7365 2073
00000c0 6e61 2079 656b 2079 6f74 7420 7972 6120
00000d0 6167 6e69 2e20 2e2e 0d20 000a 0000 0000
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200 5252 4161 0000 0000 0000 0000 0000 0000
00003e0 0000 0000 7272 6141 1b7f 0746 0002 0000
00003f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000400 0000 0000 0000 0000 0000 0000 8f32 02e2
0000410 ec58 0740 0000 0000 0000 0000 0000 0000
0000430 c30c 55f7 0000 0000 0000 0003 0000 0000
0000570 0000 0000 0000 0000 b916 01e0 0000 0000
0000590 0000 0000 0008 0000 c0ad 55f7 0002 0000
00005a0 2422 0000 0000 0000 7865 3474 6d5f 7061
00005b0 625f 6f6c 6b63 0073 0000 0000 0000 0000
00005c0 0000 0000 0000 0000 0252 0000 c229 55f7
00005d0 0002 0000 00a7 0000 2422 0000 0000 0000
00005e0 7865 3474 725f 6165 6464 7269 0000 0000
0000c00 58eb 6d90 646b 736f 7366 0000 2002 0020
0000c10 0002 0000 f800 0000 003f 00ff 0000 0000

Je peux relancer ta procédure avec fsck ?

A bientot

jamesbad000 · Le 16/09/2015, à 22:32

Qu'est ce que c'est que ce cirque ? Non ne touche à rien pour le moment.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 09/09/2015, à 22:42

Re : restauration d'image disque avec ddrescue fail

#27 Le 10/09/2015, à 00:56

Re : restauration d'image disque avec ddrescue fail

#28 Le 10/09/2015, à 08:47

Re : restauration d'image disque avec ddrescue fail

#29 Le 10/09/2015, à 08:52

Re : restauration d'image disque avec ddrescue fail

#30 Le 10/09/2015, à 11:21

Re : restauration d'image disque avec ddrescue fail

#31 Le 10/09/2015, à 11:26

Re : restauration d'image disque avec ddrescue fail

#32 Le 10/09/2015, à 12:02

Re : restauration d'image disque avec ddrescue fail

#33 Le 10/09/2015, à 15:37

Re : restauration d'image disque avec ddrescue fail

#34 Le 10/09/2015, à 17:01

Re : restauration d'image disque avec ddrescue fail

#35 Le 10/09/2015, à 22:40

Re : restauration d'image disque avec ddrescue fail

#36 Le 10/09/2015, à 23:01

Re : restauration d'image disque avec ddrescue fail

#37 Le 11/09/2015, à 13:55

Re : restauration d'image disque avec ddrescue fail

#38 Le 13/09/2015, à 21:06

Re : restauration d'image disque avec ddrescue fail

#39 Le 14/09/2015, à 12:42

Re : restauration d'image disque avec ddrescue fail

#40 Le 14/09/2015, à 13:08

Re : restauration d'image disque avec ddrescue fail

#41 Le 14/09/2015, à 13:48

Re : restauration d'image disque avec ddrescue fail

#42 Le 14/09/2015, à 13:56

Re : restauration d'image disque avec ddrescue fail

#43 Le 14/09/2015, à 18:32

Re : restauration d'image disque avec ddrescue fail

#44 Le 15/09/2015, à 09:51

Re : restauration d'image disque avec ddrescue fail

#45 Le 15/09/2015, à 12:06

Re : restauration d'image disque avec ddrescue fail

#46 Le 15/09/2015, à 13:27

Re : restauration d'image disque avec ddrescue fail

#47 Le 15/09/2015, à 13:41

Re : restauration d'image disque avec ddrescue fail

#48 Le 15/09/2015, à 20:49

Re : restauration d'image disque avec ddrescue fail

#49 Le 16/09/2015, à 22:12

Re : restauration d'image disque avec ddrescue fail

#50 Le 16/09/2015, à 22:32

Re : restauration d'image disque avec ddrescue fail

Pied de page des forums