Disque dur externe - fichiers corrompus - impossible de sauvegarder

jamesbad000 · Le 19/06/2019, à 20:07

greb a écrit :

Pour la nouvelle passe, ça peut prendre autant de temps...?

En principe un peu moins que la 1ère fois. Sauf si ça se dégrade... Les prévisions sur ce genre de sujet, c'est comme la météo...

Comme je l'ai dis, tu peux parfaitement lancer l'opération, et l'interrompre avec ctrl c si tu as besoin d'emmener ton PC.
Ensuite il suffit de relancer la dernière commande pour reprendre ou ça a été interrompu

greb · Le 20/06/2019, à 08:15

Ok, merci à vous deux.
J'ai donc créé une partition sur une partie de l'espace restant pour mes docs persos, et lancé la commande d'une nouvelle passe en backwards :

~$ sudo ddrescue -f -R -r 1 -b 4096 --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map
[sudo] Mot de passe de benjamin : 
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 126809 MB, tried: 1873 GB, bad-sector: 1873 GB, bad areas: 49

     ipos:    1739 GB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    1739 GB, non-scraped:        0 B,  average rate:   1133 kB/s
non-tried:        0 B,  bad-sector:    1841 GB,    error rate:  16916 kB/s
  rescued:  158501 MB,   bad areas:       52,        run time:  7h 46m 10s
pct rescued:    7.92%, read errors: 47490725,  remaining time:         n/a
                              time since last successful read:     11m 55s
Retrying bad sectors... Retry 1 (backwards)

Effectivement, on gagne quelques pourcents !
et c'est une bon à savoir qu'on peut couper la commande, pour la reprendre à un autre moment.
Pour info, je la coupe maintenant, et la reprendrai sûrement mardi prochain.
Merci en tous cas pour tout l'accompagnement que vous m'avez déjà offert !

greb · Le 01/07/2019, à 15:37

Cette nouvelle passe vient de se finir :

~$ sudo ddrescue -f -R -r 1 -b 4096 --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map
[sudo] Mot de passe de benjamin : 
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 268769 MB, tried: 1731 GB, bad-sector: 1731 GB, bad areas: 87

     ipos:   524288 B, non-trimmed:        0 B,  current rate:       0 B/s
     opos:   524288 B, non-scraped:        0 B,  average rate:   95827 B/s
non-tried:        0 B,  bad-sector:    1729 GB,    error rate:    311 kB/s
  rescued:  270751 MB,   bad areas:       88,        run time:  5h 44m 38s
pct rescued:   13.53%, read errors: 10166364,  remaining time:         n/a
                              time since last successful read:  3h 54m 47s
Finished

Pour info, j'ai entendu à 2-3 reprise le disque dur source 'sonner'... comme un biiip-biiip... mais ça n'a engendré aucune erreur ni n'a stoppé l'opération...

Quelle est la prochaine étape à envisager : refaire une nouvelle passe en 'forward' ? ou bien passer sur la récupération ?

D'avance merci !

Dernière modification par greb (Le 01/07/2019, à 15:39)

geole · Le 01/07/2019, à 16:28

Bonjour
Je te donne seulement mon avis. En théorie, on continue les tentatives de récupération jusqu'à ce que le disque lâche dans le but de récupérer le maxima de la strcuture qui décrit la liste des fichiers en devenant de plus en plus aggressif dans la demande.
Tu as fais le niveau 1, Je te propose d'essayer avec le niveau 3......... ( Il insistera 3 fois sur le même endroit avant de passer au secteur suivant)

sudo ddrescue -f -R -r 3 -b 4096 --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map

Cela fera certainement un peu plus de bruit

Tu peux malgré tout commencer à t'entrainer avec photorec afin de le prendre en main

..

Dernière modification par geole (Le 01/07/2019, à 16:30)

jamesbad000 · Le 01/07/2019, à 21:09

Oui avec le maigre ratio récupéré, insister est ce qu'il y a de mieux à faire. D'autant que la 2ème passe a récupérée à peu prêt autant que la 1ère et que ce qui est récupéré n'est plus à lire.

Allons y directement sans limite sur les retry avec -r -1

sudo ddrescue -f -r -1 -b 4096 --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map

Il va changer automatiquement de sens à chaque passe. Et si à un moment ça ne progresse plus entre 2 passes, il sera toujours temps d'arrêter les frais...

geole a écrit :

( Il insistera 3 fois sur le même endroit avant de passer au secteur suivant)

En fait non. Il fait une passe complète sur tous les secteurs restant à lire avec une seule tentative par secteur.
Toujours histoire d'éviter de tuer le disque en s'acharnant à un seul endroit alors que ça peut être plus facile ailleurs.
D'autant que le disque lui, fait ses retry interne à chaque échec de lecture d'un secteur sans qu'on lui demande rien.

geole · Le 02/07/2019, à 00:04

Bonsoir
Bien vu!!!
-r, --retry-passes=<n>
exit after <n> retry passes (-1=infinity) [0]

greb · Le 02/07/2019, à 08:11

Bonjour,
J'ai vu vos messages hier soir, et ai relancé sans prendre le temps de répondre.
Merci donc !
Et voilà un nouveau point :

~$ sudo ddrescue -f -r -1 -b 4096 --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map
[sudo] Mot de passe de benjamin : 
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 275381 MB, tried: 1725 GB, bad-sector: 1725 GB, bad areas: 84

     ipos:    1616 GB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    1616 GB, non-scraped:        0 B,  average rate:    803 kB/s
non-tried:        0 B,  bad-sector:    1697 GB,    error rate:  20467 kB/s
  rescued:  302876 MB,   bad areas:       92,        run time:  9h 30m 17s
pct rescued:   15.14%, read errors: 64351231,  remaining time:         n/a
                              time since last successful read:  1h 50m 39s
Retrying bad sectors... Retry 2 (backwards)

Effectivement, déjà gagné 1.5% sur près de 400Go analysés.

Lorsqu'on estimera que refaire une passe ne servira plus à grand chose, que seront les étapes suivantes ?
Et après tout cela, le disque dur source sera à jeter complet, ou bien il y a une chance de pouvoir le réutiliser ? (en total j'imagine que non, mais en partie ?)

jamesbad000 · Le 02/07/2019, à 09:50

En fait la dernière fois que j'avais plongé dans le sujet ddrescue. J'avais conclu que dans le doute, il serait bon d'utiliser le paramètre --idirect pour s'assurer qu'il test bien les secteurs un à un, et éviter qu'il rejette un bloc complet pour un seul secteur en erreur.
A l'occasion tu interrompt l'opération en cours et tu relance comme ci-dessous

sudo ddrescue -f -r -1 -b 4096 --idirect --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map

L'Etape suivante sera la remise à zéro des zones non copiées sur la cible. Car même pour un disque neuf il n'y a pas de garantie qu'il soit entièrement à 0, et en plus comme tu avais formaté des partitions, c'est certain qu'il y a des zones non initialisées.

sudo ddrescue -f  -b 4096 --fill-mode=-  /dev/zero /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map

Cela pour éviter que les outils de réparation du système de fichier ou de récup de données (photorec...), prennent des vessies pour des lanternes.

Quant à réutiliser ce disque... Comme presse papier uniquement.

geole · Le 02/07/2019, à 17:54

jamesbad000 a écrit :

En fait la dernière fois que j'avais plongé dans le sujet ddrescue. J'avais conclu que dans le doute, il serait bon d'utiliser le paramètre --idirect pour s'assurer qu'il test bien les secteurs un à un, et éviter qu'il rejette un bloc complet pour un seul secteur en erreur.

Bonjour.
Peut-être que cette codification fait aussi le bon traitement

sudo ddrescue    -f -r -1   -c 1 -b 4096 --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map

       -c, --cluster-size=<sectors>
              sectors to copy at a time [128]

jamesbad000 · Le 02/07/2019, à 19:03

Hum, non à priori le cluster-size n'a d'effet que lorsqu'il tente de faire de la copie en masse (phase 1 de la première passe nottamment).
Et certainement pas quand il est sur la passe de "scraping" qui est bien décrite comme une lecture secteur par secteur, du point de vue de ddrescue.
Il est vrai que ce n'est pas explicite dans la doc, mais ça serait contraire à la logique de ddrescue. Et si vraiment il ne lisait pas un secteur à la fois en mode scrapping avec le cluster-size par défaut à 64k, on arriverait jamais à avoir des bloc de moins de 64k en erreur.
Or je peux confirmer avoir eu des blocs plus petit et même des secteurs isolés en erreur.

En revanche ddrescue ne contrôle pas ce que le noyau fait de ses demandes de lecture. Ce dernier peut possiblement regrouper plusieurs demandes de lectures de secteurs contiguës pour envoyer un seule demande de lecture des N secteurs au disque. idirecte doit permettre d'éviter ça en adressant ses demandes directement au disque...
Après c'est juste une précaution, je n'ai jamais pu confirmer des situations ou ça se produit.

geole · Le 02/07/2019, à 19:28

Il y a quand même une chose que je ne comprends pas, C'est l'extrême rapidité de la passe de récupération faite en 5h 44m 38s
Il y a une énorme quantité de secteurs à lire, de mémoire, lire un secteur de mauvaise qualité ne se fait pas en 10 millisecondes mais plutôt 10 secondes.

greb · Le 03/07/2019, à 16:16

Je ne peux pas apporter plus d'éléments sur les options de ddrescue...
Mais pour les 5h44, effectivement, la passe ne s'est pas réalisée en ce laps de temps (malheureusement !).
En fait, j'ai du arrêter à quelques reprise l'opération (Ctrl-C) pour diverses raisons (besoin de l'ordi pour autre chose, déplacement, ...). Et donc dès que l'ordi était de nouveau dispo pour cela, je relançais la commande (et l'opération reprenait là où elle s'était arrêté, avec l'aide du fichier map j'imagine).
Ces 5h44 correspondent au temps entre le moment où j'ai relancé la commande et la fin de la passe.

Pour la présente passe, le % de rescued grimpe doucement : on en est à près de 450 GB rescued (sur 2 TB), et il reste 758 GB encore à 'scraper' :

~$ sudo ddrescue -f -r -1 -b 4096 --idirect --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map
[sudo] Mot de passe de benjamin : 
Désolé, essayez de nouveau.
[sudo] Mot de passe de benjamin : 
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 330768 MB, tried: 1669 GB, bad-sector: 1669 GB, bad areas: 100

     ipos:  758981 MB, non-trimmed:        0 B,  current rate:   6201 kB/s
     opos:  758981 MB, non-scraped:        0 B,  average rate:   1292 kB/s
non-tried:        0 B,  bad-sector:    1552 GB,    error rate:       0 B/s
  rescued:  447554 MB,   bad areas:      119,        run time:  1d  1h  6m
pct rescued:   22.37%, read errors:127114241,  remaining time:  4d  3h 47m
                              time since last successful read:          0s
Retrying bad sectors... Retry 1 (backwards)

greb · Le 04/07/2019, à 16:10

Pour info, je viens de voir le basculement entre les passes backward et forward, c'est reparti pour quelques jours. Voilà où ça en est :

~$ sudo ddrescue -f -r -1 -b 4096 --idirect --log-rates=$HOME/rescueRate.log  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 481770 MB, tried: 1518 GB, bad-sector: 1518 GB, bad areas: 134

     ipos:    1000 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    1000 MB, non-scraped:        0 B,  average rate:   1228 kB/s
non-tried:        0 B,  bad-sector:    1504 GB,    error rate:  29691 kB/s
  rescued:  496021 MB,   bad areas:      136,        run time:  3h 13m 19s
pct rescued:   24.79%, read errors: 14349345,  remaining time:         n/a
                              time since last successful read:     32m  8s
Retrying bad sectors... Retry 2 (forwards)

jamesbad000 · Le 04/07/2019, à 23:32

Tant que le volume récupéré évolue. Le temps des passes devrait se réduire...

greb · Le 05/07/2019, à 09:40

Oui, effectivement, j'ai l'impression que ça passe plus vite...

Quelque chose que j'ai remarqué : lorsque j'arrête le processus, débranche les disques durs (car besoin de l'ordi pour autre chose), et reprends, quasi systématiquement, lorsque l'opération ddrescue redémarre (là où elle s'était arrêtée), ça repart direct avec du rescue et non du read error. J'ai même tenté, lorsque je voyais que depuis un moment il n'y avait que des erreurs, d'arrêter l'opération, débrancher-rebrancher le disque dur source, et relancer l'opération, et en général, ça repart sur du rescue...
Y aurait-il une explication à ça ?

jamesbad000 · Le 05/07/2019, à 18:58

greb a écrit :

Y aurait-il une explication à ça ?

Probablement. Mais de là à te la donner, plutôt qu'une liste de suppositions plus ou moins étayées...

greb · Le 17/07/2019, à 10:10

Bonjour,
Je viens donner quelques nouvelles... qui ne sont pas bonnes...
Le ddrescue se faisait encore, au gré de la dispo de l'ordi, avec pas loin de 50% 'rescued' au final... jusqu'à cette nuit... où je me suis fait voler mon ordi, et mes 2 disques durs externes (le DD source et le DD cible)... (ils étaient tous trois bien posés sur le bureau, en train de 'ddrescuer' justement...) (les malchanceux voleurs, un ordi vieux de 8 ans, sur Lubuntu, avec un clavier français dans un pays africain anglophone ou Windows est la norme, un disque dur externe achevé, et un autre avec une partition ext4 non lisible sur Windows... pas la meilleure des prises !!).

Du coup, pour l'instant, pas d'avancement ni de récupération possible...et cette tentative de sauvegarde s'achève ici... Mais tout de même, merci beaucoup pour votre aide jusqu'à maintenant ! J'aurai au moins découvert un nouvel outil !
Mais, avec une petite lueur d'espoir, la police a fait l'inventaire des items volés. Par contre, ils me demandaient les numéros de séries. À tout hasard, est-ce que dans les infos données par les retours des commandes, dans un des posts précédents, apparaît le numéro de série des disques durs externes...?
D'avance merci !

geole · Le 17/07/2019, à 11:13

Bonjour
Lorsque les ennuis sont là!!!

Pour les numéros de serie
Du disque fichu

greb a écrit :

Bonjour,
- Et les référence du disque (Marque Maxtor sur le boitier) :

benjamin@benjamin-Vostro-3500:~$ sudo lshw -C disk
[sudo] Mot de passe de benjamin :
*-disk
description: SCSI Disk
produit: M3 Portable
fabriquant: Seagate
identifiant matériel: 0.0.0
information bus: scsi@6:0.0.0
nom logique: /dev/sdc
version: 1402
numéro de série: DFCB7E050500001F
taille: 1863GiB (2TB)
configuration: ansiversion=6 logicalsectorsize=512 sectorsize=4096

D'avance merci !
.

Il ne sera pas possible de donner le N° unique du modèle car le smartctlt a refusé de causer avec lui

Je pense trouver une autre discussion ou il y aura les deux

geole · Le 17/07/2019, à 11:42

Confirmation du numéro de série du disque source
et probablement le numéro de serie du disque neuf

jamesbad000 a écrit :

disque source
1,8T sdd1 ntfs Maxtor /media/benjamin/Maxtor
source usb-Seagate_M3_Portable_DFCB7E050500001F-0:0> ../../sdd
disque cible
1,9T sde1 ntfs sauvegarde /media/benjamin/sauvegarde
ata-ST4000LM024-2AN17V_WCK3CNMB[ -> ../../sde

Le modèle est ST4000LM024-2AN17 voir https://www.seagate.com/www-content/pro … 1609fr.pdf
Le numéro de série est WCK3CNMB voir https://www.lowendtalk.com/discussion/1 … understand

Dernière modification par geole (Le 17/07/2019, à 17:14)

greb · Le 17/07/2019, à 16:49

Re-bonjour,
Merci beaucoup de l'aide !

J'ai testé le numéro de série que proposé pour le disque cible sur l'outil support-garantie de LaCie (étant un disque de cette marque). Cela me renvoie bien quelque chose, mais le disque dur lui-même (sans l'enveloppe du boitier), en l'occurrence un BarraCuda 2.5, avec exactement les mêmes réfs de modèle. Mais j'ai retrouvé la boîte d'emballage du disque dur entre temps, et l'info est marquée dessus, avec le numéro de série du produit complet.
Et pour le disque source, l'outil de garantie (Seagate cette fois) ne me renvoie rien, mais peut-être parce qu'il n'est plus sous garantie... Mais le texte du retour de commande semble sans équivoque ("numéro de série: DFCB7E050500001F") donc j'ai pris cette référence.
On verra si ça sert vraiment à retrouver les objets volés...

Mais encore une fois, merci pour toute cette aide sur plusieurs dizaines de messages !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 19/06/2019, à 20:07

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#52 Le 20/06/2019, à 08:15

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#53 Le 01/07/2019, à 15:37

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#54 Le 01/07/2019, à 16:28

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#55 Le 01/07/2019, à 21:09

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#56 Le 02/07/2019, à 00:04

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#57 Le 02/07/2019, à 08:11

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#58 Le 02/07/2019, à 09:50

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#59 Le 02/07/2019, à 17:54

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#60 Le 02/07/2019, à 19:03

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#61 Le 02/07/2019, à 19:28

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#62 Le 03/07/2019, à 16:16

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#63 Le 04/07/2019, à 16:10

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#64 Le 04/07/2019, à 23:32

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#65 Le 05/07/2019, à 09:40

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#66 Le 05/07/2019, à 18:58

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#67 Le 17/07/2019, à 10:10

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#68 Le 17/07/2019, à 11:13

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#69 Le 17/07/2019, à 11:42

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

#70 Le 17/07/2019, à 16:49

Re : Disque dur externe - fichiers corrompus - impossible de sauvegarder

Pied de page des forums