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

geole · Le 13/10/2019, à 16:18

Bonjour
Fais d'abord celle-ci .

sudo ddrescue -f -c1 -n /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 tu pourras passer à celle que tu indiques mais il faudra t'attendre à une certaine lenteur.
c'est le même principe de suivi.

Le mode graphique pour afficher les lieux d'erreurs est bien .
Tu peux aussi le faire en ligne de commandes à tout instant

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

wc -w /$HOME/green1to5diskBADBLOCS.log
cat /$HOME/green1to5diskBADBLOCS.log

Ajout
Pendant la tentative de copie des blocs illisibles, il a été rapporté les phénomènes suivants
a) Le disque peut se mettre à chauffer et disparaître. La commande plante.
Il faut attendre quelques heures puis la relancer.
b) Pendant plusieurs heures, aucune lecture ne réussit.
Il faut arrêter la commande (ctrl c ) attendre quelques heures puis la relancer
c) Les têtes de lectures cassent. C'est terminé pour les tentatives de recopie.
d) Il est très rare que 100% soient récupérables. Il faudra savoir arrêter à un moment donné.

J'ai constaté
a) qu'il y a pas mal d'erreurs en début de disque, C'est souvent à cet endroit que les descriptions de fichiers sont stockées
b) qu'il y a énormément d'erreurs à la fin du disque. Dnas une partition NTFS de windows, cest très rare qu'il y ait des données utilisateurs

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

geole · Le 13/10/2019, à 17:15

Shinji a écrit :

J'ai installé par curiosité gsmartcontrol dont voici le log d'erreur :

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-65-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   141   141   140    -    471
  7 Seek_Error_Rate         -OSR-K   200   200   000    -    0
  9 Power_On_Hours          -O--CK   097   097   000    -    2449
197 Current_Pending_Sector  -O--CK   195   195   000    -    1341
200 Multi_Zone_Error_Rate   ---R--   001   001   000    -    55916
 Error 27657 [8] occurred at disk power-on lifetime: 2444 hours   Error: UNC 8 sectors at LBA = 640726456
Error 27656 [7] occurred at disk power-on lifetime: 2441 hours  Error: UNC 8 sectors at LBA =  640726456
Error 27655 [6] occurred at disk power-on lifetime: 2441 hours   Error: UNC at LBA = 640726456
Error 27654 [5] occurred at disk power-on lifetime: 2441 hours   Error: UNC at LBA = 640726400
Error 27653 [4] occurred at disk power-on lifetime: 2441 hours   Error: UNC at LBA  = 640726456
 Error 27652 [3] occurred at disk power-on lifetime: 2441 hours  Error: UNC at LBA  = 640726456
 Error 27651 [2] occurred at disk power-on lifetime: 2441 hours Error: UNC at LBA =  640726456
 Error 27650 [1] occurred at disk power-on lifetime: 2441 hours  Error: UNC at LBA = 640726400

On voit que le disque a 471 secteurs qui ont été lus avec difficultés et qui ont du être remplacés par d'autres mais qu'il en reste 1341 en attente de remplacement.
qu'il y a eu 55916 tentatives de lectures/écriture provoquant 27657 erreurs mémorisés
Que la dernière datet d'il y a 8 heures et porte sur 8 secteurs commençant au N° 640726456
C'était pareil 3 heures avant où il y avait aussi le N° 640726400 pour 1 secteur
Dans tous les cas, l'erreur était UNC abbréviation de UNreCoverable

Avec cette quantité d'erreurs ton disque est probablement non réutilisable.

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

geole · Le 13/10/2019, à 18:12

Shinji-san a écrit :

J'ai lu dans la doc ubuntu-fr ceci :
Évitez d'utiliser une partition NTFS pour accueillir une image disque de taille importante (plus de quelques Go). Plusieurs personnes ont rapporté que la récupération ralentit au fur et à mesure de la récupération, à telle point qu'il est impossible de finir la récupération.
Qu'en penses-tu ?

Dans quelques heures ou dans quelques jours, tu vas arrêter de tenter de lire les secteurs illisibles.
Il faudra donner la partition dupliquée à windows pour remettre en état.
Peut-être que la remise en état sera excellente. Peut-être pas.
Pour se prémunir du risque, je t'ai proposé de dupliquer la copie faite dans une autre partition puisque tu as la chance d'avoir un gros disque.

Cette remarque m'a interpellé. Je n'ai pas la possibilité de dupliquer 1,5 To mais j'ai réussi à dupliquer 190 Go. Voici mes quelques remarques

1) Duplication dans une partition non-formatée avec cette commande
sudo dd if=/dev/zero of=/dev/sdc14 bs=64K count=2899169 status=progress
189993517056 bytes (190 GB, 177 GiB) copied, 1190 s, 160 MB/s
2899169+0 enregistrements lus
2899169+0 enregistrements écrits
189999939584 bytes (190 GB, 177 GiB) copied, 1190,04 s, 160 MB/s
Ma surprise a été de voir que le débit commençait vers 200 M B/s et diminuait lentement

2) Duplication dans une partition formatée EXFAT avec cette commande
sudo dd if=/dev/zero of=/mnt/sdc14/fic.img bs=64K count=2899169 status=progress
561577984 bytes (562 MB, 536 MiB) copied, 1 s, 562 MB/s
189867622400 bytes (190 GB, 177 GiB) copied, 1190 s, 160 MB/s
2899169+0 enregistrements lus
2899169+0 enregistrements écrits
189999939584 bytes (190 GB, 177 GiB) copied, 1190,92 s, 160 MB/s

df -h | grep sdc14
/dev/sdc14 197G 177G 20G 91% /mnt/sdc14
C'est la même remarque que pour le non-partitionné et le même débit.

3) Duplication dans une partition formatée BTRFS avec cette commande
sudo dd if=/dev/zero of=/mnt/sdc14/fic.img bs=64K count=2899169 status=progress
189945348096 bytes (190 GB, 177 GiB) copied, 1199 s, 158 MB/s
2899169+0 enregistrements lus
2899169+0 enregistrements écrits
189999939584 bytes (190 GB, 177 GiB) copied, 1199,35 s, 158 MB/s
Même remarque , c'est un petit peu moins rapide.. J'ai oublié de relever le taux de remplissage.

4) Duplication dans une partition formatée EXT4 avec cette commande
sudo dd if=/dev/zero of=/mnt/sdc14/fic.img bs=64K count=2899169 status=progress
189864869888 bytes (190 GB, 177 GiB) copied, 1283 s, 148 MB/s
2899169+0 enregistrements lus
2899169+0 enregistrements écrits
189999939584 bytes (190 GB, 177 GiB) copied, 1283,87 s, 148 MB/s

df -h | grep sdc14
/dev/sdc14 193G 178G 5,7G 97% /mnt/sdc14
Le débit se stabilise entre 147 et 146 MB/s

5) Duplication dans une partition formatée NTFS avec cette commande
sudo dd if=/dev/zero of=/mnt/sdc14/fic.img bs=64K count=2899169 status=progress
125435904 bytes (125 MB, 120 MiB) copied, 1 s, 125 MB/s
189918281728 bytes (190 GB, 177 GiB) copied, 1595 s, 119 MB/s
2899169+0 enregistrements lus
2899169+0 enregistrements écrits
189999939584 bytes (190 GB, 177 GiB) copied, 1595,71 s, 119 MB/s

df -h | grep sdc14
/dev/sdc14 197G 179G 19G 91% /mnt/sdc14
On constate bien qu'écrire un fichier de 197 Go en NTFS est pénalisant par rapport aux autres formats de partitions.
J'ai fait un suivi visuel
Les 10 premières minutes stable à 121 Mb/s
Les 6 minutes suivantes stable à 120 Mb/s
La suite stable à 119 Mb/s
Mon relevé semble incompatible avec la moyenne générale de 119 MB/s
Je ne sais pas si cela aurait continué à diminuer en débit si j'avais copié 1,5 To.
J'ai pris une unité de 64Ko comme travaille ddrescue cependant 1 Mo est certainement préférable.

Je te suggère de conserver ta seconde partition formatée en NTFS et de suivre la duplication lorsque tu la lanceras afin de voir s'il y a dégradation au fur et à mesure de l'avancement de la copie.

Pour copier, tu devras d'abord monter la partition de réception sur un point de montage

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

en remplaçant N par le numéro de la partition réceptrice que tu auras formatée

et tu copieras avec cette commande

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

Dernière modification par geole (Le 13/10/2019, à 18:15)

moko138 · Le 13/10/2019, à 18:58

  9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       2449
  5 Reallocated_Sector_Ct   0x0033   141   141   140    Pre-fail  Always       -       471
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       264
197 Current_Pending_Sector  0x0032   195   195   000    Old_age   Always       -       1341

En y repensant, ça m'évoque fortement le résultat d'un atterrissage de têtes.

Mais la représentation graphique https://framapic.org/gNSs28xYe3Aq/5mM7b2ekd4na.png ne confirme pas cette impression.

rmy · Le 13/10/2019, à 20:40

dans ta commande il y a deux "f", un seul suffit…
Ensuite heu… -r27 -c1 c'est un peu abusé je crois, saufsi tu as un mois devant toi… un -r1 -c16 devrait déjà être largement beaucoup il me semble.

geole · Le 13/10/2019, à 22:51

On verra bien. Mais -c16 c'est incorrect. Je maintiens -c1 Je me demande d'ailleurs si, dans l'absolu, la première commande ne devrait pas avoir -c1 vu que, maintenant, la plupart des disques dispose d'un cache.

rmy · Le 14/10/2019, à 00:09

pourquoi incorrect selon toi geole ? -r27 -c1, de mémoire, ça signifie qu'il va faire des tentatives de copies sur des secteurs potentiellements HS ou n'ayant pas répondu, 27 fois, et cela secteur par secteur…
avec -r1 -c16 on ne retente qu'une fois la lecture avant un jump de 16 secteurs… ce qui me semble déjà très acceptable sur un disque dans cet état, non ?

moko138 · Le 14/10/2019, à 00:12

geole,
As-tu remarqué :

man tune2fs | grep -B1 -A4 Card

?

rmy · Le 14/10/2019, à 00:33

@moko, je ne comprends pas ton dernier commentaire, est-ce en lien avec ta proposition précédente de modification de la doc ddrescue ?

moko138 · Le 14/10/2019, à 00:46

Non : je m'étais figuré que rmy de diskcard.fr et

Remy Card

ne faisaient qu'un.
Veuillez tous m'excuser si j'étais à côté de la plaque !

rmy · Le 14/10/2019, à 08:46

moko138 a écrit :

Non : je m'étais figuré que rmy de diskcard.fr et
Remy Card
ne faisaient qu'un.
Veuillez tous m'excuser si j'étais à côté de la plaque !

Effectivement, c'est pas moi :-)

geole · Le 14/10/2019, à 13:06

rmy a écrit :

pourquoi incorrect selon toi geole ? -r27 -c1, de mémoire, ça signifie qu'il va faire des tentatives de copies sur des secteurs potentiellement HS ou n'ayant pas répondu, 27 fois, et cela secteur par secteur…
avec -r1 -c16 on ne retente qu'une fois la lecture avant un jump de 16 secteurs… ce qui me semble déjà très acceptable sur un disque dans cet état, non ?

Bonjour
Moi aussi, j'avais pensé que tu étais rmy expert en réparation de disque.
J'ai donc hésité avant de faire ma remarque et j'ai pensé que tu n'avais pas pris le temps de lire le début de la discussion où il est écrit

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (AF)
Device Model:     WDC WD15EARS-00Z5B1
Sector Size:      512 bytes logical/physical

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0

Donc disque avec des secteurs physiques de 512 octets qui est la valeur par défaut dans la commande avec mécanique du disque en excellant état qui n'a donc pas besoin d'être ménagée.

et noté que la première commande faite était

sudo  ddrescue  -f   -n

....
ce qui sous-entend -c128 puisque ddrescue --help dit
-b, --sector-size=<bytes> sector size of input device [default 512]
-c, --cluster-size=<sectors> sectors to copy at a time [128]

Donc, lorsque les phases de récupérations rapides sont terminées et qu'il ne reste que les parties défectueuses, il faut travailler à l'unité physique et pas par paquets de plusieurs unités.

Nota si la structure du disque avait indiqué que la taille physique était de 4096 au lieu de 512 , j'aurais proposé une première commande avec

sudo  ddrescue  -f   -n      -b4096   -c1024

....
et une dernière commande avec -c8

Pour le paramètre -r27 c'est quasiment équivalent au paramètre -r1 avec consigne de relancer 26 fois lorsque la commande est terminée. Mais au moins l'utilisateur est libéré de l'action de suivi pendant un certain temps.
Souvent, un disque H.S. a une mécanique en mauvais état. Il est alors possible de proposer seulement -r2 puis un point avec smarctl.
Lorsqu'un secteur est illisible, le paramètre -r27 ne signifie pas qu'il faut relancer immédiatement la lecture du secteur. Le secteur qui sera lu à la suite du secteur illisible sera celui qui suit.
Lorsqu'on sera arrivé en fin de disque, on repart pour une relecture complète en diminuant de 1 la valeur -r mais en commençant par la fin du disque. (Je ne sais pas si cela à un gros intérêt à ce niveau).

rmy · Le 14/10/2019, à 13:46

geole a écrit :

Moi aussi, j'avais pensé que tu étais rmy expert en réparation de disque.

En récupération de données, oui, celui-ci c'est moi. Pas Rémy Card, un expert en systèmes de fichiers semble-t-il.

geole a écrit :

WD15EARS-00Z5B1
Sector Size: 512 bytes logical/physical

Oui, j'ai bien vu ça.

Nous ne sommes donc pas en désaccord sur ce que signifie la commande, mais sur la pertinence et la manière de l'utiliser.
Il y a à ce stade 31675kB (61350 secteurs) non copiés, avec 646 erreurs. Autant dire du gruyère dans le zones non copiées. Ces zones se répartissent visiblement sur la fin du disque en majorité.
Lancer un -r27 -c1 va être considérablement plus long qu'un -r1 -c16 ce qui va permettre d'aller vers des blocs non splités de 8K dans les zones concernées (c'est déjà pas mal…). Le lancer en reverse va commencer par la fin du disque, où il y a beaucoup plus d'erreurs, et donc augmenter les chances d'une défaillance du disque dur avant que les zones pertinentes (début du disque, MFT, NTFS…) ne soient retentées…

Je comprends l'intention de tenter de faire mieux, mais à un moment il faut savoir faire la part des choses entre une amélioration pertinente et un acharnement pas forcément utile à mon avis.

Je persiste donc à préconiser d'être plus raisonnable sur la taille des blocs pour la lecture, et beaucoup plus raisonnable sur le nombre de retry. Je valide l'idée de lire en reverse, parfois cela améliore la situation et des secteurs non lisibles en FW le sont en R. Par contre, en limitant la zone de lecture de manière à rester dans le début du disque.

ddrescue source dest log -d -r1 -c16 -R -s 40G

Shinji-san · Le 14/10/2019, à 17:09

Bonjour,

Je vais être obligé de retarder la suite des réparations le temps que l'alerte météo ne passe. Je ne voudrai pas que des coupures de courant surviennent pendant l'opération qui m'a l'air des plus périeuse.

Pour la suite, ne pouvant pas rester chez moi tout le temps à surveiller les opérations, je vais mettre en place une ou plusieurs solutions afin de prendre le contrôle à distance via ssh, remote et/ou teamviewer..
Par contre, en cas de coup dur survenant à distance, y'a t'il un moyen de mettre en pause la commande et de couper à distance l'alimentation du disque malade afin de limiter la casse ?

geole · Le 14/10/2019, à 19:07

Bonjour

Le plus simple est que, avant de partir, tu appuies sur les touches Ctrl c
Que tu fasses une copie de l'écran par copier/coller que tu mettras dans la discussion
Puis que tu éteignes ton ordinateur.

A ton retour, tu rallumes et tu reprends la commande.
je n'avais pas pensé à favoriser la récupération du début de la partition NTFS qui contient un maxima de descripteurs de fichiers afin de conserver le maxima de noms de fichiers avec l'option
-s 40G

il me semble que tu n'es pas à quelques jours près. " Évidement un beau jour il a refusé de se monter, alors je l'ai débranché pour éviter que ça empire. "

Dernière modification par geole (Le 14/10/2019, à 19:08)

geole · Le 14/10/2019, à 19:45

rmy a écrit :

Je persiste donc à préconiser d'être plus raisonnable sur la taille des blocs pour la lecture, et beaucoup plus raisonnable sur le nombre de retry. Je valide l'idée de lire en reverse, parfois cela améliore la situation et des secteurs non lisibles en FW le sont en R. Par contre, en limitant la zone de lecture de manière à rester dans le début du disque.
ddrescue source dest log -d -r1 -c16 -R -s 40G

Bonjour.
Je suis en train de penser que, ,lorsque la partition est en NTFS, si je ne me trompe pas:
- Le début de la partition contient les descripteurs de fichiers: D'où l'idée de copier avec le maxima de tentatives la première partie de la partition avant de faire la fin de la partition (paramètre -ipos).
- Le principe du NTFS est de mettre les données au maxima dans le début du disque et seulement en fin de disque lorsqu'il s'emplit ( contrairement au format EXT4 qui étale).
- Du temps des vieux windows, il y avait un outil "defragm" qui affichait les secteurs non utilisés.
Ma question, ne serait-il pas possible de trouver un utilitaire ubuntu qui indique le dernier secteur utilisé?
Cela éviterait alors de copier des zones qui n'ont aucune donnée....

Dans la documentation de ddrescue, le paragraphe 2.4.1.2 indique

à titre d'exemple
Faire la copie des secteurs endommagés
sudo ddrescue       -d  -f  -R  -r3   -b512  -c1          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f  -R  -r27   -b512  -c1          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi

J'ai pensé que la qualité mécanique du disque permettait de ne pas faire la première des deux.
Cependant, si on veut y aller progressivement, peut-être faudrait-il modifier cet partie de documentation pour écrire quelque chose de ce style

Faire la copie des secteurs endommagés
sudo ddrescue       -d  -f        -r1   -b512  -c64          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f  -R  -r2   -b512  -c32          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f        -r3   -b512  -c16          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f  -R  -r4   -b512  -c8            /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f        -r5   -b512  -c4            /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f  -R  -r6   -b512  -c2            /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f       -r27   -b512  -c1          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi

ou

Faire la copie des secteurs endommagés
sudo ddrescue       -d  -f       -r2   -b512  -c32         /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f  -R  -r4   -b512  -c8            /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f        -r6   -b512  -c2          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi
sudo ddrescue       -d  -f   -R  -r27   -b512  -c1          /dev/sda    /dev/sde    /home/ubuntu/dd/suivi

Car, à mon avis, il faut malgré tout finir avec -c1 pour un disque ayant des secteurs physiques de 512 Octets.

rmy · Le 14/10/2019, à 21:45

geole a écrit :

- Du temps des vieux windows, il y avait un outil "defragm" qui affichait les secteurs non utilisés.
Ma question, ne serait-il pas possible de trouver un utilitaire ubuntu qui indique le dernier secteur utilisé?
Cela éviterait alors de copier des zones qui n'ont aucune donnée....

Oui et non : Il y a des outils (ddrutiliy, et en particulier ddru_ntfsbitmap) qui permettent de faire une map des secteurs uitilisés, et donc ensuite de se limiter avec -m MAP à l'espace utilisé à cloner. Mais ça, c'est avec un FS sain. Et un FS sain, ça monte…

geole a écrit :

Dans la documentation de ddrescue, …/…
Car, à mon avis, il faut malgré tout finir avec -c1 pour un disque ayant des secteurs physiques de 512 Octets.

à mon avis non, mais c'est un choix d'expérience plutôt que de "perfection à tout prix".
"Avant" ddrescue, il y avait dd_rescue et ddrhelp. L'idée était de copier par dichotomie. En découpant (le trimming/scrapping de ddrescue) en premier les blocs les plus gros. Donc quant tu laisses tourner ça un temps qui tend vers l'infini, bah tu as le même résultat qu'un ddrescue avec -d -b512 -c1 -r1… Ou qu'un dd --noerror --direct…

Pour moi, c'est refuser d'exploiter ce pourquoi ddrescue est fait : réaliser un clone le plus efficacement et intelligemment possible, prenant en compte qu'il y a des erreurs. Tout est une question de granularité acceptée. Disons autrement : ici c'est un WD, qui ne décroche pas lorsqu'il rencontre un secteur en attente de réallocation… cool. Mais donnerais tu la même commande avec un Seagate, qui va disparaître chaque fois que ce sera le cas (je veux dire qu'il ne sera plus reconnu par l'OS, donc nécessité de reprendre manuellement, avec un -MA, et en ayant manuellement débranché et rebranché le DD) ??

Ce que je veux dire, c'est que quand tu n'as "que" 30Mo d'erreur, que tu arrives éventuellement à réparer et monter ta partition, et que tu auras (peut-être) quelques fichiers impactés, bah t'es hyper contant avec un disque dans cet état.

Note pour la suite : Il faudra IMPÉRATIVEMENT faire un clone secondaire avant de tenter de réparer le FS (c'ets du NTFS, donc avec ntfsfix ça peut marcher, et parfois mieux qu'avec un chkdsk).

@Shinji-san : je te conseille effectivement aussi de ne pas laisser tourner en ton absence, surtout avec un -r27… mais pour répondre à ta question :

hdparm -Y

man hdparm a écrit :

-Y Force an IDE drive to immediately enter the lowest power con‐
sumption sleep mode, causing it to shut down completely. A hard
or soft reset is required before the drive can be accessed again
(the Linux IDE driver will automatically handle issuing a reset
if/when needed). The current power mode status can be checked
using the -C option.

geole · Le 15/10/2019, à 10:20

Bonjour RMY
Je suis d'accord avec toi qu'un professionnel ne peut pas se permettre de prendre 3 jours pour récupérer un disque. Surtout qu'on est quasiment certain de ne pas tout récupérer.
Je pense qu'un professionnel passera très peu de temps sur cette étape de récupération fine

A mon avis, il répare alors le système de fichier, et sauve tous les fichiers intacts puis il fait un WIPE des fichiers sauvés et lance photorec pour récupérer ce qui a une signification.

Pour un particulier qui n'a jamais pris le temps de sauver ses données, il peut prendre un peu plus de temps sur la première phase mais on ne saura jamais combien cela va lui permettre de récupérer de fichiers en plus. Peut-être 0 peut-être beaucoup plus.
Nota, si la partition était en EXT4, il y aurait moyen de savoir si le secteur illisible n'est pas alloué, est alloué à un fichier, est alloué à une description de répertoire.
Jamesbad000 sait faire, je connais à peu près le principe, l'idée est alors de regarder la liste des secteurs non récupérés pour trouver ceux qui appartiennent à des directory et de paramétrer finement pour ne récupérer que ces secteurs en faisant l'impasse sur les secteurs décrivant des fichiers ou rien du tout.

Nota. Je pense que tant qu'il y a de la vie, il y a de l'espoir.
J'ai même vu des discussions de réparation où les disques chauffaient fortement au moment de la lectures des blocs illisibles et finissaient par disparaître. Il suffisait alors d'attendre plusieurs heures que cela refroidisse avant de relancer la commande qui repartait pour quelques heures et récupérait encore un peu... Chose qui pourrait certainement être évitée avec le paramètre --pause-on-error=600 Cela mettrait alors des semaines ....

Nota. il est prévu de dupliquer les données avant de réparer la partition.
Si à la suite de la réparation, le résultat n'est pas très bon, il est toujours possible de restaurer et de repartir pour une dernière recherche jusqu'à ce que la mécanique du disque émetteur lâche...

Dernière modification par geole (Le 15/10/2019, à 10:23)

rmy · Le 15/10/2019, à 10:27

si le système est sain, avec ddru_ntfsfindbad tu trouves la liste des fichiers impactés.

Shinji-san · Le 17/10/2019, à 16:57

Bonjour,

Je suis très content que ce thread suscite l'intérêt et que vous vous investissiez autant à propos de mes données, vraiment, merci beaucoup !!
Mais du coup, je suis un peu perdu quand à la commande à lancer ^^

Si je comprends bien, j'ai l'impression qu'il y a plusieurs stratégies possibles. Car il ne me semble pas qu'un consensus ait émergé. Et je ne crois pas avoir le niveau de compétence pour faire un choix.

rmy · Le 17/10/2019, à 17:04

ça fait la même chose sauf que la commande préconisée par geole va essayer de te fournir un résultat beaucoup plus précis (isoler les secteurs HS un à un) et durer beauuuuuuuucoup plus longtemps. Tu peux prendre l'une ou l'autre, en tout cas si tu utilises "-R", mets un "-s 40G".

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

J'ai fait la sauvegarde comme me le préconisait Geole :

geole a écrit :

Je te suggère de conserver ta seconde partition formatée en NTFS et de suivre la duplication lorsque tu la lanceras afin de voir s'il y a dégradation au fur et à mesure de l'avancement de la copie.
Pour copier, tu devras d'abord monter la partition de réception sur un point de montage
sudo    mount   -v  /dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-partN    /mnt
en remplaçant N par le numéro de la partition réceptrice que tu auras formatée
et tu copieras avec cette commande
sudo dd if=/dev/disk/by-id/ata-WDC_WD40EZRZ-00GXCB0_WD-WCC7K6SEK4NT-part1  of=/mnt/DUPLIgreen1to5disk.img  bs=1M status=progress

Donc j'ai une image de ma première copie sur la seconde partition du disque de 4To.

---------

Donc maintenant, si je comprends bien, que je suive l'une ou l'autre des stratégies, il faut que je lance avant tout :

sudo ddrescue -f -c1 -n /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

Vous confirmez ?

---------

Ensuite, j'ai plusieurs possibilités :
stratégie geole, longue, avec pas mal d'interventions de ma part mais bien plus fine :

sudo ddrescue -f -d -f -R -s 40G -r27 -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

stratégie rmy

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

J'ai pensé à quelque chose est-ce qu'il ne serait pas intéressant de lancer tout d'abord la commande d'rmy qui sembleplussafe sur le disque qui ne devrait pas le tuer (si j'ai bien compris) puis ensuite celle de geole qui ira au bout du bout en prenant son temps. Qu'en pensez-vous ?

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

Bonjour.
Je comprends que tu as déja copié dans un fichier la duplication de la partition en mauvais état.
c'est prématuré.

Maintenant, tu lances la commande de RMY le nombre de fois que tu désires.
Tant qu'elle recupérera des secteurs, tu peux la relancer.
Avec un peu de chances, elle peut tout récupérer.

Ensuite, si elle n'a pas tout récupéré, tu lance ma commande qui cherche unitairement.
à un moment donné, tu en auras marre, tu peux alors l'arrêter.
C'est à ce moment là que tu dois sauver la copie dans un fichier de l'autre partition

Puis tu mets a zéro les parties non copiées avec la commande que je vais ajouter
puis tu lances windows et tu lui demandes de faire un check de la partition dupliquée,

Si le fsck se passe bien et que tu récupéres la totalité des répertoires, c'est presque gagné.
mais s'il se passe mal, tu restores la partition avec le fichier et tu recommences ma commande afin qu'elle puisse en récupérer encore un peu.

En dernier recours, aprés la réparation de windows, tu sauvegardes tous les fichiers dans l'autre partition et tu supprimes tous les fichiers sauvés avec une commande wipe et tu utiliseras photorec pour récupérer les derniers fichiers qui n'ont pas été accrochés à la sructure des répertoires de windows. Bien entendu, ces fichiers n'auront pas de nom.

A tous. Après avoir lu l'algorythme officiel de récupération écrit en anglais, je pense que ma proposition est correcte puisque la derniere passe du premier passage fait déjà du traitement unitaire. Du moins c'est ce que je comprend

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

Shinji-san · Le 22/10/2019, à 08:54

Ok oui. Je te remercie une nouvelle fois pour tes explications.

Hier, j'ai fait tourner la commande dont voici les résultats :

https://framapic.org/tMnNwsm5h7L9/TzuNewa7sY7H.png
https://framapic.org/93HaHM1zgD6J/a9Tys6DvthHR.jpg

Je ne sais pas à quel rythme je vais pouvoir continuer car nous sommes une nouvelle fois en attente d'évènements météos risquant de faire fluctuer l'électricité. Et j'imagine que les microcoupures, c'est pas génial, d'autant plus pour un disque "fatigué" et en pleine tentative de sauvegarde.

_{Modération : merci d'utiliser des images de petite taille (300x300) ou des miniatures pointant sur ces images (Des hébergeurs comme Toile Libre ou TDCT'Pix le permettent).}

Dernière modification par cqfd93 (Le 22/10/2019, à 09:24)

moko138 · Le 22/10/2019, à 09:50

Shinji-san a écrit :

Hier, j'ai fait tourner la commande dont voici les résultats :
https://framapic.org/tMnNwsm5h7L9/TzuNewa7sY7H.png
https://framapic.org/93HaHM1zgD6J/a9Tys6DvthHR.jpg

/!\ Un retour de commande, c'est du texte et ça se donne sous forme de texte !
Pas sous forme de captures
- dans lesquelles on ne peut pas faire de copier-coller !
- et qui pollue à cause du stockage sur serveurs et des transferts !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 13/10/2019, à 16:18

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

#27 Le 13/10/2019, à 17:15

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

#28 Le 13/10/2019, à 18:12

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

#29 Le 13/10/2019, à 18:58

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

#30 Le 13/10/2019, à 20:40

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

#31 Le 13/10/2019, à 22:51

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

#32 Le 14/10/2019, à 00:09

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

#33 Le 14/10/2019, à 00:12

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

#34 Le 14/10/2019, à 00:33

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

#35 Le 14/10/2019, à 00:46

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

#36 Le 14/10/2019, à 08:46

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

#37 Le 14/10/2019, à 13:06

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

#38 Le 14/10/2019, à 13:46

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

#39 Le 14/10/2019, à 17:09

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

#40 Le 14/10/2019, à 19:07

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

#41 Le 14/10/2019, à 19:45

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

#42 Le 14/10/2019, à 21:45

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

#43 Le 15/10/2019, à 10:20

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

#44 Le 15/10/2019, à 10:27

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

#45 Le 17/10/2019, à 16:57

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

#46 Le 17/10/2019, à 17:04

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

#47 Le 20/10/2019, à 11:05

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

#48 Le 20/10/2019, à 11:46

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

#49 Le 22/10/2019, à 08:54

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

#50 Le 22/10/2019, à 09:50

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

Pied de page des forums