#151 Le 12/01/2016, à 21:17
- pst57600
Re : [Résolu] récupération de partition EXT4 (encore une !!)
ubuntu@ubuntu:~$ sudo mount /dev/loop1 /mnt
mount: block device /dev/loop1 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
ubuntu@ubuntu:~$ j'ai booté à partir d'un DVD... je ne sais pas si cela a un rapport ?
j'ai maintenant un DD disque 2 en bas, dans la barre à gauche mais je ne peux rien faire :
open
Disque 2 (+ gras)
unlock from launcher
dans files / devices : unable to access disque 2
Error mounting /dev/loop1 at /media/ubuntu/Disque 2: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/loop1" "/media/ubuntu/Disque 2"' exited with non-zero exit status 32: mount: block device /dev/loop1 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or soubuntu@ubuntu:~$ sudo dmesg | tail
[54268.600665] EXT4-fs (loop1): group descriptors corrupted!
[54376.127712] EXT4-fs (loop1): ext4_check_descriptors: Block bitmap for group 0 not in group (block 3497988096)!
[54376.127718] EXT4-fs (loop1): group descriptors corrupted!
[54376.369039] EXT4-fs (loop1): ext4_check_descriptors: Block bitmap for group 0 not in group (block 3497988096)!
[54376.369044] EXT4-fs (loop1): group descriptors corrupted!
[54394.795072] systemd-hostnamed[12683]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
[54419.609246] EXT4-fs (loop1): ext4_check_descriptors: Block bitmap for group 0 not in group (block 3497988096)!
[54419.609251] EXT4-fs (loop1): group descriptors corrupted!
[54487.472908] EXT4-fs (loop1): ext4_check_descriptors: Block bitmap for group 0 not in group (block 3497988096)!
[54487.472913] EXT4-fs (loop1): group descriptors corrupted!
ubuntu@ubuntu:~$ Dernière modification par pst57600 (Le 12/01/2016, à 21:27)
Hors ligne
#152 Le 12/01/2016, à 23:35
- jamesbad000
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Forcément si on avait pu le monter sans faire de réparation ça aurait été trop facile.
Mais non le DVD n'est probablement pas en cause.
Avant de faire un bilan de la situation et décider comment on poursuit. Je voudrais m'assurer de la constance du défaut d'alignement de la partition.
Pour cela il faut tenter à nouveau la recherche de super blocs de secours sur loop1 avec testdisk. (cf post #143)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#153 Le 13/01/2016, à 00:05
- pst57600
Re : [Résolu] récupération de partition EXT4 (encore une !!)
ubuntu@ubuntu:~$ sudo dumpe2fs -h /dev/loop1
dumpe2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: Disque 2
Last mounted on: /media/Disque 2
Filesystem UUID: 3fed9c14-4c79-4ad0-b6d8-153dd87c37b5
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244191232
Block count: 1953506636
Reserved block count: 97675331
Free blocks: 558394055
Free inodes: 243641639
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 558
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Mon Nov 23 19:16:31 2015
Last mount time: Wed Dec 31 23:00:24 2008
Last write time: Thu Dec 24 05:49:42 2015
Mount count: 16
Maximum mount count: -1
Last checked: Mon Nov 23 19:16:31 2015
Check interval: 0 (<none>)
Lifetime writes: 1102 GB
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: ab495ba9-5a88-496a-91c8-4fadf78a497e
Journal backup: inode blocks
FS Error count: 2188
First error time: Sun Nov 29 07:13:23 2015
First error function: ext4_find_entry
First error line #: 1309
First error inode #: 2
First error block #: 0
Last error time: Thu Dec 24 05:49:42 2015
Last error function: ext4_find_extent
Last error line #: 901
Last error inode #: 113836936
Last error block #: 0
Journal superblock magic number invalid!
ubuntu@ubuntu:~$ sudo testdisk /dev/loop1
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
ubuntu@ubuntu:~$ TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/loop1 - 8001 GB / 7452 GiB - 15628053127 sectors (RO)
Partition Start End Size in sectors
ext4 0 15628053087 15628053088 [Disque 2]
superblock 0, blocksize=4096 [Disque 2]
To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device
>[ Quit ]
Return to Advanced menuHors ligne
#154 Le 13/01/2016, à 00:50
- jamesbad000
Re : [Résolu] récupération de partition EXT4 (encore une !!)
aia. Il ne trouve que le 1er super bloc. Donc là le niveau d'incertitude sur l'état des données est à son maximum.
C'est étonnant qu'avec de tels symptôme le smartmon ne fasse pas apparaître la moindre anomalie. Ou alors c'est la free box qui à fait n'importe quoi dès le départ et à finie par s'y perdre.
A ce stade, il faut faire le point :
1- on n'obtiendra rien du système de fichier sans faire une réparation avec e2fsck. (Certitude)
2 - mais une réparation dans des condition habituel peut aussi donner un résultat inexploitable et compromettre ensuite la récupération de fichiers avec un outils comme photorec.
Et là la situation étant tout à fait hors norme je subodore que la réparation ne vas pas donner de bon résultat.
3 - La parade habituelle au risque de compromettre des tentatives ultérieur est de faire une copie complète du disque sur un autre (disque de taille au moins identique. On peut éventuellement se débrouiller avec une image répartie sur plusieurs disques)
(option compromise par le décalage imprévisible qui sera très probablement répercuté sur la copie)
4 - ton système de fichier (au moins le début) étant alignée au milieu d'un secteur. Même si on le répare sur place (sans copie) Les données ne seront de toute façon pas exploitables dans des conditions normales (obligé de passer par un /dev/loop). (Certitude)
5 - on peut envisager de palier au point ci-dessus en décalant toutes les données. Mais c'est risqué sans backup et ça risque d'être très long. (option compromise par des décalage imprévisible)
6 - photorec aurait l’inconvénient de récupérer les fichiers sans nom ni répertoire d'origine (certitude). Et il y aura probablement de la perte sur les gros fichiers qui sont forcément un peu fragmentés. (impact du décalage imprévisible)
7 - photorec nécessitera forcément un autre disque qui recevra les fichiers récupéré (donc pas loin de 5Go)
8 - Je n'ai pas de certitude sur le fait que ton disque sera réutilisable ou non après un reformatage complet.
9 - s'il s'agit d'un problème d'électronique (les données sont bien la ou elle devrait être, mais c'est mal transmis par l'électronique du disque) Une entreprise spécialisée sera certainement à même de restituer toutes les données.
Le temps de méditer sur tout ça, je fait une recherche sur ce symptôme de décalage.
(les liens fournis par moko138 me semblent relatif à des problèmes mineurs sans rapport avec le problème de décalage rencontré ici)
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#155 Le 13/01/2016, à 01:31
- pst57600
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Merci pour le temps passé.
Je vais aussi réfléchir de mon côté.
Hors ligne
#156 Le 13/01/2016, à 13:21
- Bougron
Re : [Résolu] récupération de partition EXT4 (encore une !!)
aia.
.......
6 - photorec aurait l’inconvénient de récupérer les fichiers sans nom ni répertoire d'origine (certitude). Et il y aura probablement de la perte sur les gros fichiers qui sont forcément un peu fragmentés. (impact du décalage imprévisible)7 - photorec nécessitera forcément un autre disque qui recevra les fichiers récupéré (donc pas loin de 5Go)
8 - Je n'ai pas de certitude sur le fait que ton disque sera réutilisable ou non après un reformatage complet.
6 - Effectivement, les blocks ne sont pas forcement consécutifs....
7 - Le calcul (1953506636 - 558394055) * 4096 = 5,734 To .
7 - Le calcul (1953506636 - 558394055 - 97675331) * 4096 = 5,314 To .
8 - L'utilitaire de test de seagate sera à passer http://knowledge.seagate.com/articles/f … anguage=fr
voir si la procédure de retour du disque va s'appliquer http://forum.ubuntu-fr.org/viewtopic.ph … #p21289641
J'aurais été incapable de diagnostiquer le décalage des blocks.
Cela me semble un cas où la duplication intégrale du disque avant réparation n'est pas évidente à conseiller.
Ce que je n'avais pas fait car la qualité du disque ne me semblait pas dégradée.
Comme la piste du firwmare est fort probable, il faut espérer que le décalage constaté lors de la lecture est toujours le même quelques soient les secteurs. Ce qui n'est pas sur du tout et surtout qu'il n'y a pas eu d'écritures avec ce défaut de calcul d'adressage.
Dernière modification par Bougron (Le 14/01/2016, à 13:41)
Hors ligne
#157 Le 13/01/2016, à 16:12
- Bougron
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonjour
jamesbad000 a écrit :
A le résultat du hd m'étonne mais c'est tout à fait intéressant
Il y a là dedans les éléments d'un superbloc ext ça ne fait aucun doute. Je reconnais à vu de nez la signature avec le magic number 53EF, plus loin le nom de volume "Disque 2" et le dernier répertoire de montage "/media/Disque"
Mais semble décalé de 4 octets vers la gauche. Ou alors je m'embrouille quelque part.
Ca nécessite un peu de réflexion et de calcul..
.
Probablement une simple erreur de calcul........qui est rectifiée depuis. Le décalage est de 380 par la droite, et ce n'est toujours pas un multiple de 64
40*512+380+1080= 55B4 en base hexa soit comme contenu "53 ef".
bougron@ubuntu14-04-3:~$ sudo hd -s1080 -n2 /dev/sda5
00000438 53 ef |S.|
0000043a
bougron@ubuntu14-04-3:~$ Dernière modification par Bougron (Le 13/01/2016, à 16:13)
Hors ligne
#158 Le 13/01/2016, à 18:43
- pst57600
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonsoir,
Depuis un moment, je me demande si ce décalage n'est pas dû à la technologie utilisée pour ce DD : SMR de seagate
"shingled magnetic recording, avec lequel les pistes se chevauchent comme les tuiles d'un toit, les têtes de lecture étant plus fines que les têtes d'écriture".
cela ne pourrait-il pas tromper les commandes linux ou testdisk ?
Cf.
http://www.clubic.com/disque-dur-memoir … artie.html
http://www.seagate.com/files/www-conten … 1411us.pdf
Hors ligne
#159 Le 13/01/2016, à 22:59
- jamesbad000
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonsoir.
7 - Le calcul (1953506636 - 558394055) * 4096 = 5,734 To .
Il faut aussi retirer
Reserved block count: 97675331Cela me semble un cas où la duplication intégrale du disque avant réparation n'est pas évidente à conseiller.
Ce que je n'avais pas fait car la qualité du disque ne me semblait pas dégradée.
La sauvegarde à aussi tout son sens avec un système de fichier qu'on soupçonne fortement dégradé...
Permet de tenter différentes options en revenant en arrière après une tentative foireuse.
Comme la piste du firwmare est fort probable, il faut espérer que le décalage constaté lors de la lecture est toujours le même quelques soient les secteurs.
Firmeware j'en doute. Car le problème ne serait pas apparu brutalement. Panne d'électronique est plus probable. Ou alors on cumule plusieurs problème matériel (free box) + logiciel (firmware versus driver qui ne s'entendent pas)
Mais je confirme que le décalage est très probablement pas constant, autrement je n'explique pas qu'on ne trouve pas de superbloc de secours en s'alignant sur la position du 1er superbloc. Et le décalage n'est pas non plus localisé au début, car la recherche de superbloc en faisant démarrer la partition de façon standard sur le début du secteur 40 n'a rien donnée non plus.
Depuis un moment, je me demande si ce décalage n'est pas dû à la technologie utilisée pour ce DD : SMR de seagate
Ca me parait peu crédible car si les têtes se mettaient à mélanger les donnés de pistes adjacentes par exemple, ça produirait une erreur de somme de contrôle (Chaque secteur contient en plus des données une somme de contrôle qui est calculée à partir des données écrites. Revérifiée après l'écriture pour garantir que les données écrites sont correctes, et revérifiée à chaque lecture...)
cela ne pourrait-il pas tromper les commandes linux ou testdisk ?
L'architectures interne du disque est inconnue de l'os. Que les pistes soient concentrique, en x, ou même qu'il n'y en ait pas (SSD) est masqué par le disque lui même. L'os commande la lecture ou l'écriture d'un n° de secteur, et charge au disque d'aller lire ou écrire au bon endroit ou de répondre qu'il n'a pas pu le faire.
un secteur défectueux peux même se voir remplacer par un secteur de réserve situé à un autre endroit, sans que l'os en sache rien
En revanche un problème dans la transmission des données entre le disque et l'os n'est pas totalement à écarter.
Seulement j'ai cru comprendre que le disque n'était pas plus lisible sur windows. Remarque qu'en dernier ressort ça serait à retenter maintenant qu'on a repositionné la partition sur le secteur 40.
L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)
Hors ligne
#160 Le 14/01/2016, à 02:42
- Bougron
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonsoir
Bien sur, il faut aussi soustraire les réservés pour connaître la taille utilisée.
Exemple typique du SSD à qui on demande d'écrire 10 blocs consécutifs dans la partition P3 et que le firmware du ssd peut écrire en 10 endroits sur la totalité du disque.
autre exemple: On demande d'écrire un secteur de 512 octets alors que l'unité physique fait 4096 octets.
J'ai cherché sans succès comment on pouvait reconnaître un super block un peu à la manière dont photorec reconnaît un bloc d'images d'un bloc de document. Je ne suis pas sur du tout que testdisk lit bloc par bloc. Je pense qu'il utilise un algorythme pour dire les supers blocs doivent se trouver à tels endroits, La preuve, c'est qu'en utilisant les valeurs qu'il donne, e2fsck dit que ce n'est pas un superbloc.
Il me semble que le windows de référence ne sait pas traiter une partition de 3 To. Espérons simplement que cela ne soit pas lui qui ait mis la partition de 8To dans cet état. De plus, il faudrait être certain que EXT2FSD (ou un de ses semblables) ne soit pas buggé pour une partition dépassant 2,2 To
Hors ligne
#161 Le 14/01/2016, à 03:39
- Bougron
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonsoir.
Je ne sais pas ce que cette piste va donner.
Il faudrait que tu lances PHOTOREC
et qu'au début tu choisisses "file-opt" , que tu désélectionnes tous les choix de fichiers .
que tu sélectionnes uniquement le choix "ext2/ext3/ext4 Superbloc"
que tu valides la sélection nouvelle qui sera faite
puis que tu lances la recherche.
b1510@b1510:~/Bureau/recup_dir.2$ ls -rtl
total 7920656
-rw-r--r-- 1 root root 4195352576 janv. 14 13:05 f2338888.ext
-rw-r--r-- 1 root root 1073741824 janv. 14 13:09 f20975616.ext
-rw-r--r-- 1 root root 2841640960 janv. 14 13:11 f23597560.ext
-rw-r--r-- 1 root root 2105 janv. 14 13:27 report.xml
b1510@b1510:~/Bureau/recup_dir.2$ Dernière modification par Bougron (Le 14/01/2016, à 14:31)
Hors ligne
#162 Le 14/01/2016, à 11:39
- pst57600
Re : [Résolu] récupération de partition EXT4 (encore une !!)
bonjour,
merci pour cette nouvelle piste.
c'est parti pour quelques heures...
PhotoRec 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 8001 GB / 7452 GiB (RO) - ST8000AS0002-1NA17Z
Partition Start End Size in sectors
Unknown 0 0 1 972801 80 63 15628053168 [Whole disk]
0 files saved in /home/ubuntu/Desktop/test/recup_dir directory.
Recovery completed.
[ Quit ]reste photorec... pour les fichiers...
Dernière modification par pst57600 (Le 15/01/2016, à 14:24)
Hors ligne
#163 Le 25/01/2016, à 15:39
- pst57600
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonjour,
petit retour pour clôturer
ben c'est une "happy end" !
voilà comment j'ai fait :
j'ai fait de la place sur mon NAS dlink pour disposer d'environ 6To (2X3To en JBOD) , branché le 8To en SATA sur le PC WIN10 , utilisé Restorer Ultima Pro network
http://www.bitmart.net/
et lancé la recherche des partitions puis des fichiers
... sauf erreur, il a tout retrouvé 
les fichiers avec leur nom et l'arborescence !
Evidemment ce fut long pour 447 000 fichiers dans 75 000 dossiers (5 j, environ 24h par To)
seul bémol : les caractères accentués ne sont pas restitués correctement
exemple : T├®l├®chargements pour Téléchargements
Pour éviter que cela ne se reproduise, j'ai investi dans un NAS Synology 416j 4 DD WD RED X5TO en RAID5 qui sera backupé
le 8To reste à vérifier ...
merci encore à Bougron et Jamesbad000 pour leur assistance.
Dernière modification par pst57600 (Le 25/01/2016, à 15:40)
Hors ligne
#164 Le 25/01/2016, à 21:20
- Bougron
Re : [Résolu] récupération de partition EXT4 (encore une !!)
Bonsoir
Merci pour ton retour et ton idée de trouver un équivalent "photorec" en windows. Le fait qu'il ait retrouvé les noms de fichiers montre que la structure décrivant les fichiers n'était pas cassée.... Elle n'était donc probablement pas EXT4.
Reste quand même pour le disque le problème de sa qualité http://forum.ubuntu-fr.org/viewtopic.ph … #p21289521
Refaire un smartctl pour voir l'évolution.....
Dernière modification par Bougron (Le 25/01/2016, à 21:20)
Hors ligne