Tentative de récupération d'un disque dont le montage échoue

rmy · Le 29/10/2019, à 23:23

très bonne nouvelle !

moko138 · Le 30/10/2019, à 00:01

geole a écrit :

puis lancer la commande suivante à partir de l'application windows power shell lancée en mode administrateur (en remplaçant X par la lettre trouvée)
chkdsk   X:  /f   

Non, c'est

chkdsk X: /b

puisque le support matériel a changé (et que la couche logicielle est NTFS). Cf. Maintenance des supports..., message #2

geole · Le 30/10/2019, à 12:54

Bonjour Moko138
Je n'ai pas jugé utile de proposer cette commande

chkdsk   X:  /r

En effet, il est inutile de vérifier que les secteurs non alloués à des fichiers sont en bon état. car dans peu de temps, toute la partition va de nouveau être écrasée et lorsque l'opération de récupération sera terminée, il est fort probable que la partition soit supprimée.

moko138 · Le 30/10/2019, à 13:25

geole,
je crois que ton dernier message est hors-sujet parce que tu as zappé le début de l'explication de /b par Microsoft.

geole · Le 30/10/2019, à 13:53

Shinji-san a écrit :

....
Pour la suite, je pensais donc copier tout ça sur un autre disque et tenter d'utiliser l'image conservée sur la seconde partition afin de grappiller des fichiers par ci par là. En effet, on peut savoir en explorant le disque, ce qui a été sauvé, mais pas ce qui est perdu. De plus, il me semble que même la commande de rmi n'était même pas allée jusqu'au bout. Donc je pensais la relancer, refaire une image, puis lancer la commande de geole pour essayer de fignoler au maximum, puisque le disque malade tourne encore. Il me semble que cette commande tentée de récupérer chacun des secteurs.

Bonjour
Je me joins à rmy pour les félicitations.

J'ai compris que tu allais continuer à tenter de récupérer le maxima possible.
Tu as tenté de décrire ce que tu vas faire. Je ne suis pas certain de bien comprendre... Voici la démarche:

1) Sauver les répertoires récupérés ailleurs est une bonne chose si tu veux regarder le contenu pendant la suite de l'opération car pendant cette opération, les répertoires vont de nouveau devenir inacessibles!

2) La commande chkdesk a fait un gros travail en éliminant pas mal de choses. En conséquence, la partition n'est plus identique. Il est nécessaire de la restaurer à partir de son sauvetage avant de relancer la commande ddrescue.

3) La commande de restauration est l'inverse de la commande de sauvetage donc cela devrait être;

sudo mount -v /dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part2 /mnt

sudo dd of=/dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part1  if=/mnt/DUPLIgreen1to5disk.img  bs=1M status=progress

4) La commande ddrescue que tu avais lancée était me semble-t-il :

sudo ddrescue -f -d -f -R -s 40G -r1 -c16 /dev/disk/by-id/ata-WDC_WD15EARS-00Z5B1_WD-WMAVU2792075-part1 /dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part1 /$HOME/green1to5disk.log

Tu as dis qu'elle n'était pas terminée.
Comme tu le sais, il n'est pas évident de trouver le meilleur paramétrage.
- Dire qu'il faut se limiter à une certaine taille est une très bonne chose car tu as montré que la fin du disque est sacrément en mauvais état.
De plus, il est possible qu'il n'y ait aucun fichier dans la fin du disque.
Question: Te souviens-tu du taux de remplissage de la partition émettrice. Une fourchette suffit.
10% 50% 90% 100%
- Je persiste à dire que mettre la valeur c16 au lieu de c1 me surprend énormément.
- Le nombre de passes à faire peut être choisi à r1 et tu peux lancer le nombre de fois que tu voudras tant que cela récupére et que tu as du temps libre.

Dès maintenant, tu devrais republier l'état actuel de la récupération:
à) Sous forme de résumé avec cette commande:

 ddrescuelog  -tvv  /$HOME/green1to5disk.log

b) Sous forme détaillée avec ces commandes:

touch $HOME/green1to5diskBADBLOCS.log
sudo ddrescuelog -l- -b512 /$HOME/green1to5disk.log >$HOME/green1to5diskBADBLOCS.log

wc -w /$HOME/green1to5diskBADBLOCS.log
head -1000  /$HOME/green1to5diskBADBLOCS.log

geole · Le 30/10/2019, à 14:17

moko138 a écrit :

geole,
je crois que ton dernier message est hors-sujet parce que tu as zappé le début de l'explication de /b par Microsoft.

Pour plus de précision

https://docs.microsoft.com/fr-fr/windows-server/administration/windows-commands/chkdsk a écrit :

Paramètres
..
/f Corrige les erreurs sur le disque. Le disque doit être verrouillé. Si chkdsk ne peut pas verrouiller le lecteur, un message s’affiche vous demandant si vous souhaitez
...
/r Localise les secteurs défectueux et récupère des informations lisibles. Le disque doit être verrouillé. /r comprend les fonctionnalités de l' /f, avec l’analyse .
...
/b NTFS uniquement : Efface la liste des clusters défectueux sur le volume et rerecherche les erreurs dans tous les clusters alloués et libres. /b comprend les fonctionnalités de /r. Utilisez ce paramètre après avoir Imaging un volume sur un nouveau disque dur.
.....

Finalement, la correction a été faite en automatique. Je pense c'est l'option /f qu'elle a utilisée

Il n'y a aucun interêt à regarder l'état des secteurs défectueux dans cette partition de réception.

moko138 · Le 30/10/2019, à 15:09

Bon, puisqu'il subsiste manifestement un malentendu, j'explique :

Sur un support matériel dégradé (c'était justement la situation de départ) certaines zones du support - et, par contrecoup, du système de fichiers aussi - sont illisibles.
Une fois réalisée l'image sur un support sain - et c'est ce que vous avez fait - il n'y a aucune raison de conserver la liste des clusters défectueux (défectueux sur le précédent support).

Et c'est la remise à zéro de cette liste, qui est la particularité de /b.

Voilà pourquoi ni /f ni /r ne sont adaptés à la nouvelle situation, sur support sain.

geole · Le 30/10/2019, à 16:36

Merci de préciser clairement la méthode qui a dupliqué cette liste.
Si cette liste est dans la partition, elle va bientôt être détruite.
Si cette liste n'est pas dans la partition, elle n'a pas pu récupérer la liste des secteurs défectueux de l'autre disque..
Dans la partition de reception, il ne peut y avoir que des bons secteurs sauf ceux qui sont mauvais nativement. S'il manque des secteurs de l'autre disque, cela n'a aucun impact sur la qualité des secteurs de receptions qui n'ont pas encore été remis à zéro et qui conservent donc leur ancien contenu (Ce qui peut être pénalisant si la suite se passe avec photorec)..

NOTA, Je pense que tu confonds avec une duplication d'un disque entier dans un disque entier dont la fin du disque gère ce qui est appelé "g-list"
et qu'il y a confusion dans la traduction "Utilisez ce paramètre après avoir Imaging un volume sur un nouveau disque dur."

Je considère qu'il n'y a pas de copie dans le disque dur mais dans un volume du disque dur.
Je vais essayer de remonter au plus près avec la phrase originale " Use this parameter after imaging a volume to a new hard disk drive."

Dernière modification par geole (Le 30/10/2019, à 17:56)

Shinji-san · Le 30/10/2019, à 17:53

Merci Geole

Oui, je pensais exactement à la démarche que tu décris dans ton post 80 !

Il était malheureusement pas mal plein, je dirais aux alentours de 90 ou 95%.

Je vais commencer donc par lancer un simple cp de cette partition vers un autre disque. Je pense que ce sera plus rapide en ligne de commande sous linux. Sauf si tu connais quelque chose de plus rapide ou plus adapté.

geole · Le 30/10/2019, à 17:59

J'adore la commande cp -rvu

Dernière modification par geole (Le 03/11/2019, à 22:49)

moko138 · Le 30/10/2019, à 18:32

geole a écrit :

Merci de préciser clairement la méthode qui a dupliqué cette liste.

/b, /f et /r étant des options de chkdsk qui vérifie des partitions, (alias "volume" dans la terminologie de Microsoft),
1) ton "Je pense que tu confonds avec une duplication d'un disque entier" est erroné ;
2) je déduis de

Microsoft a écrit :

/b NTFS seulement : efface la liste des clusters défectueux sur le volume et l'analyse à nouveau tous les clusters alloués et libres pour les erreurs. /b inclut les fonctionnalités de /r. Utilisez ce paramètre après imaging un volume vers un nouveau lecteur de disque dur.

que la "liste des clusters défectueux sur le volume" est dans le volume, (tout comme en ext la liste des badblocks est dans la partition).

Par conséquent, "la méthode qui a dupliqué cette liste" est ton ddrescue.

rmy · Le 30/10/2019, à 19:26

geole a écrit :

NOTA, Je pense que tu confonds avec une duplication d'un disque entier dans un disque entier dont la fin du disque gère ce qui est appelé "g-list"

oO

Non non la G list c'est pas ça.…

La liste des BADBLOCKS est une variable du système de fichier c'est elle qui est modifiée par le /b de chkdsk et c'est aussi elle qui est réinitialisée par le -b de ntfsfix. donc ici ça avait déjà été fait ;-)

La G-LIST ou "GROWING-LIST" n'est absolument pas stockée sur des secteurs lisibles du disque, ça fait partie des infos structurelles stockées en dehors des données utilisateur (c'est à dire les secteurs accessibles à l'utilisateur). Regarde du côté de la SMART pour plus d'infos, mais en fait il y a plusieurs liste de secteurs HS qui elles sont des infos matérielles, et persistantes (même si tout ton disque est formaté). En l'occurrence une liste de l'état des secteurs HS à la sortie usine (donc non affectés) puis des secteurs en attente de dréallocation, puis des secteurs HS réalloués.

Tu comprends bien j'imagine que faire une passe d'écriture de zéros sur un disque ne va pas réparer des secteurs réalloués et qu'ils le resteront.

moko138 · Le 30/10/2019, à 19:56

rmy,
S'il te plaît, la P-list et la G-list (ça fait des années que je cherche l'info) sont-elles stockées
- sur le circuit imprimé ?
- ou sur le plateau ?
- ou ça dépend du fabricant et du modèle ?

rmy · Le 31/10/2019, à 09:15

moko138 a écrit :

rmy,
S'il te plaît, la P-list et la G-list (ça fait des années que je cherche l'info) sont-elles stockées
- sur le circuit imprimé ?
- ou sur le plateau ?
- ou ça dépend du fabricant et du modèle ?

(et la TDlist et la NRGlist…) emplacement variable suivant marque/modèle, sur les plateaux.

Shinji-san · Le 03/11/2019, à 15:25

Bon, la copie était en cours depuis plusieurs jours mais la tempête a eu raison de l'opération. Il y eu plusieurs petites coupures de courant dont une, suffisamment importante pour couper l'alimentation du PC, apparemment.

Y a t'il un moyen :
De savoir si l'opération était terminée ?
Et si ce n'est pas le cas, de reprendre où elle en était ?
Ou alors, de répertorier les fichiers et dossiers non encore copiés afin de ne pas reprendre depuis le début ?

rmy · Le 03/11/2019, à 16:24

tu en étais à la cope des fichiers n'est-ce pas, avec un cp -rv ?

Tu peux reprendre avec un

rsync -rtv --progress --size-only [source/] [destination/]

Comme ça les fichiers déjà copiés ne seront pas copiés encore…

Dernière modification par rmy (Le 03/11/2019, à 16:26)

Shinji-san · Le 03/11/2019, à 16:37

Oui. Super, merci beaucoup !!

Dernière modification par Shinji-san (Le 03/11/2019, à 16:37)

Shinji-san · Le 03/11/2019, à 22:23

J'ai du m'absenter pour une urgence.A mon retour, je m’aperçois que mon second disque de save de 4To ne veut plu se monter. Je crois que j'ai la gigne T_T

Voici le message d'erreur :

Error mounting /dev/sdc1 at /media/shinji/1B3111C46BE42873: Command-line `mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000" "/dev/sdc1" "/media/shinji/1B3111C46BE42873"' exited with non-zero exit status 13: $MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sdc1': Erreur d'entrée/sortie
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

Du coup je n'ai pas pu lancer le rsync.

geole · Le 03/11/2019, à 22:38

Bonsoir.
c'est une conséquence de la coupure électrique.
Comme tu as un windows de disponible, lance-le et branche le disque. Il devrait réparer automatiquement et ne stresses pas.

Dernière modification par geole (Le 03/11/2019, à 22:46)

rmy · Le 03/11/2019, à 23:28

y'a des chances qu'un ntfsfix fasse l'affaire aussi. Et au pire, t'as rien perdu d'autre que du temps…

Shinji-san · Le 10/11/2019, à 20:19

J'ai enfin un peu de temps pour vous tenir au courant. Et bien le démarrage de Windows n'a rien fait. J'ai l'impression que pour lui, il n'y a aucun problème car il arrive à monter le disque et je peux l'explorer sans soucis via Windows.

Du coup, je ne sais pas trop quelle commande lancer via Windows car je n'ai pas tout compris à votre discussion au sujet de chkdsk

J'ai voulu me rabattre sur ntfsfix, mais j'ai également eu peur de faire une bêtise

geole · Le 10/11/2019, à 20:49

Bonsoir.
Je pense que windows a remis en état de façon automatique.
Tu n'as plus qu'à revenir dans ubuntu, remonter les partitions et continuer avec la commande proposée par rmy

ou relancer avec la commande cp en ajoutant l'option -u afin de ne pas recopier les fichiers déjà copiés. http://www.linux-france.org/article/man … /cp-1.html

Dernière modification par geole (Le 10/11/2019, à 20:54)

Shinji-san · Le 11/11/2019, à 09:56

Bonjour,
Merci Geole !!
Après plusieurs redémarrage, effectivement Windows a résolu le soucis. Pas au premier coup, c'est étrange, mais ça fonctionne, c'est l’essentiel. J'ai relancé le rsync mais il y a eu des erreurs alors, je le relance avec une redirection de la sortie erreur dans un fichier afin de pouvoir vérifier.

Ensuite, si je ne fais pas erreur, il faudra donc que je supprime la partition résultante du travail de ddrescue sur ma première partition de 1.5To afin de la reconstituer à partir de l'image conservée sur la seconde partition de 2.5To. Et ce, parce qu'il y a eu réparation par chkdisk. Donc il faut que je reparte avant l'intervention de Windows, c'est bien ça ?

Et puis, j’envisage de relancer le ddrescue qui vérifie une fois chaque secteur des premiers 40Go, puis refaire une image au cas où (je ne sais pas si c'est nécessaire).
Et ensuite si le disque n'a pas crashé, tenter une fois chaque secteur sur tout le disque.

Vous pensez que je ne fais pas erreur dans mes démarches ?

Dernière modification par Shinji-san (Le 11/11/2019, à 09:56)

geole · Le 11/11/2019, à 11:36

Bonjour.
Lorsque tu auras fait le point avec rsync, tu n'as pas besoin de reformater la partition ayant reçu le travail de ddrescue puisque tu vas la reconstituer dans sa totalité à partir du fichier que tu as fabriqué avant de faire la commande fsck .

Ensuite, tu lances le ddrescue sur les 40 Go.
puis sur la totalité de la partition puisque tu as dit qu'elle était pleine à près de 95%.

sudo ddrescue -f -d -f -R  -r1 -c1 /dev/disk/by-id/ata-WDC_WD15EARS-00Z5B1_WD-WMAVU2792075-part1 /dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part1 /$HOME/green1to5disk.logà

puis une troisième fois pour trois tentatives si tu veux.

sudo ddrescue -f -d -f -R  -r3  -c1  /dev/disk/by-id/ata-WDC_WD15EARS-00Z5B1_WD-WMAVU2792075-part1 /dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part1 /$HOME/green1to5disk.log

Tu n'as besoin de refaire une image que lorsque tu décides de lancer la réparation soit avec la commande ntfsfix ou chkdsk et que si tu trouves qu'après la réparation, il y a encore trop de fichiers absents et que tu penses qu'en refaisant la manipulation de remise en état, tu pourrais encore en récupérer par ddrescue. Ce qui n'est possible que si tu as arrêté ddrescue alors qu'il réussisait encore en récupérer de temps en temps.
Mais comme tu ne peux pas savoir le résultat,
1) Tu fais préventivement l'image.
2) Tu mets à zéro, dans la partition sortie, les secteurs qui n'ont pas réussi à être copiés avec cette commande:

sudo  ddrescue --fill-mode=- --force --synchronous /dev/zero  /dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part1 /$HOME/green1to5disk.log

3) Tu lances la réparation ( chkdsk ou ntfsfix )

Je t'expliquerais plus en détail comment récupérer les données dont les fichiers n'ont pas étè accrochés avec la commande chkdsk ou ntfsfix
Le principe est le suivant
a) Sauver tous les fichiers reconnus.
b) Mettre à zero tous les fichiers reconnus. ( on a déjà mis â zero les secteurs non récupérés)
C) Lancer photorec pour qu'il tente de reconnaitre ce qu'il y a dans tous les secteurs qui ne sont pas à zéro.

Dernière modification par geole (Le 11/11/2019, à 11:55)

Shinji-san · Le 11/11/2019, à 22:57

Je ne connais pas la commande à lancer afin de reconstituer la partition d'1.5To à partir du .img.
D'après la doc du site, j'ai l'impression que ce devrait être :

dd if=/media/shinji/6A89F48E2B8D6559/DUPLIgreen1to5disk.img of=/media/shinji/Stockage\ green\ 1.5T/ bs=1M status=progress

Mais je ne veux pas faire de bêtise.

D'ailleurs, les disques doivent être montés, n'est-ce pas ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#76 Le 29/10/2019, à 23:23

Re : Tentative de récupération d'un disque dont le montage échoue

#77 Le 30/10/2019, à 00:01

Re : Tentative de récupération d'un disque dont le montage échoue

#78 Le 30/10/2019, à 12:54

Re : Tentative de récupération d'un disque dont le montage échoue

#79 Le 30/10/2019, à 13:25

Re : Tentative de récupération d'un disque dont le montage échoue

#80 Le 30/10/2019, à 13:53

Re : Tentative de récupération d'un disque dont le montage échoue

#81 Le 30/10/2019, à 14:17

Re : Tentative de récupération d'un disque dont le montage échoue

#82 Le 30/10/2019, à 15:09

Re : Tentative de récupération d'un disque dont le montage échoue

#83 Le 30/10/2019, à 16:36

Re : Tentative de récupération d'un disque dont le montage échoue

#84 Le 30/10/2019, à 17:53

Re : Tentative de récupération d'un disque dont le montage échoue

#85 Le 30/10/2019, à 17:59

Re : Tentative de récupération d'un disque dont le montage échoue

#86 Le 30/10/2019, à 18:32

Re : Tentative de récupération d'un disque dont le montage échoue

#87 Le 30/10/2019, à 19:26

Re : Tentative de récupération d'un disque dont le montage échoue

#88 Le 30/10/2019, à 19:56

Re : Tentative de récupération d'un disque dont le montage échoue

#89 Le 31/10/2019, à 09:15

Re : Tentative de récupération d'un disque dont le montage échoue

#90 Le 03/11/2019, à 15:25

Re : Tentative de récupération d'un disque dont le montage échoue

#91 Le 03/11/2019, à 16:24

Re : Tentative de récupération d'un disque dont le montage échoue

#92 Le 03/11/2019, à 16:37

Re : Tentative de récupération d'un disque dont le montage échoue

#93 Le 03/11/2019, à 22:23

Re : Tentative de récupération d'un disque dont le montage échoue

#94 Le 03/11/2019, à 22:38

Re : Tentative de récupération d'un disque dont le montage échoue

#95 Le 03/11/2019, à 23:28

Re : Tentative de récupération d'un disque dont le montage échoue

#96 Le 10/11/2019, à 20:19

Re : Tentative de récupération d'un disque dont le montage échoue

#97 Le 10/11/2019, à 20:49

Re : Tentative de récupération d'un disque dont le montage échoue

#98 Le 11/11/2019, à 09:56

Re : Tentative de récupération d'un disque dont le montage échoue

#99 Le 11/11/2019, à 11:36

Re : Tentative de récupération d'un disque dont le montage échoue

#100 Le 11/11/2019, à 22:57

Re : Tentative de récupération d'un disque dont le montage échoue

Pied de page des forums