Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Disque dur externe - fichiers corrompus - impossible de sauvegarder

geole

Bonjour.

Le principe est de recopier le mieux possible ce qui est lisible de ton disque sur un autre puis de tenter d'y recopier ce qui n'est pas en bon état jusqu'à ce que mort s'en suive.
Puis tenter de boucher les trous dans la copie.

Si je ne me suis pas trompé, le disque qui ne va pas est celui-ci

1,8T sdc                               
  1,8T └─sdc1 ntfs    Maxtor             /media/benjamin/Maxtor

Tu vas déjà commencer à installer l'application ddrescue https://doc.ubuntu-fr.org/ddrescue

sudo apt install gddrescue

Comme ton disque fait 4 To, je propose de ne pas utiliser la copie dans un fichier mais dans une partition. Surtout que la réparation finale sera faite par windows.

1) Tu devras rebrancher le disque qui ne marche pas très bien.
2) Tu identifies le disque par exemple avec la commande sudo blkid
3) Tu commences par dire que smartcl est inutile en mettant la bonne lettre sdc?

smartctl -o   off    /dev/disque_abimé.

4) Tu identifies la taille de la partition à copier avec cette commande

sudo fdisk -l

Il faudra que tu divises par deux la taille qui est indiquée en secteurs pour avoir le nombre de blocs de 1Ko
Tu ajoutera 16 pour avoir une petite réserve.
5) Tu lances une application de création de partition par exemple Disques qui est préinstallée si tu es en version 18.04
Cela permet de choisir l'unité en KO sinon gparted. Il te faudra encore diviser par 1024 pour avoir en Mo. Tu arrondis à l'utité supérieure.
6) Tu fabriques donc une partition (ntfs ).
7) Tu fabriques aussi une seconde parrtion de taille identique. (Elle pourrait servir lorsque la duplication devra être réparée par windows.)
8) Tu fabriques une troisième partition en EXT4 avec le reste. Elle ne devrait pas servir sauf à y mettre les fichiers de suivi.
9) On va identifier tout cela avec la commande suivante

sudo ls -l /dev/disk/by-id/

10) Tu pourras commencer à lire le document ddrescue . Si tu es courageux, tu peux faire une proposition de ligne de commande. Sinon tu attends qu'elle te soit proposée.

Nota avec un disque de 2 To et qui ne fonctionne pas très bien, cela va prendre plusieurs jours, Cependant s'il y a un arrêt. On reprend à l'endroit arrêté.

greb

Bonjour geole,

Merci beaucoup pour ton message !
Donc effectivement, c'est bien le Maxtor de 1.8 To qui capote.
ggrescue bien installé.
J'ai lancé la commande sudo blkid, qui m'indique que c'est bien sur /dev/sdc.
Par contre, j'obtiens cette 'erreur' lorque je lance la désactivation de smartctl :

~$ smartctl -o off /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-51-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/sdc: Unknown USB bridge [0x0bc2:0x61b5 (0x1402)]
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

Pour le point 4) (taille de la partition), j'obtiens pour le disque /dev/sdc :

Disque /dev/sdc : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x54b34f25

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdc1    *           64 3907024064 3907024001   1,8T  7 HPFS/NTFS/exFAT

J'ai considéré la taille en secteurs de /dev/sdc1, c'est bien cela ?
Ce qui me donne, divisé par 2, ajouté de 16, et arrondi à l'entier supérieur : 1953512017 ... Ko... c'est bien ça ?

Je m'apprête à formater mon disque dur.
Si j'ai bien compris, j'aurai 2 partitions NTFS de 1953512017 Ko, + 1 partition ext4 avec tout l'espace restant...?
Je renverrai après le repartitionnement les retours de la commande du point 9).

Merci en tous cas !

geole

J'avais oublié que smartcl dialoguait mal avec le disque
Je te fais confiance pour la division
Lorsque sdc1 aura été tant bien que mal recopié dans sdX1 , on dupliquera sdX1 dans sdX2 avant de demander à windows d'en réparer un.
Comme cela, si la réparation est mauvaise, on aura un secours fiable.

greb

Pour la division, justement, je ne me sens pas très à l'aise avec ces histoires de conversion Ko-Mo, d'autant plus qu'avec Gparted, ce sont des Mio qui sont demandés...
La conversion donnerait : 1953512017 / 1024 = 1907726,5791 --> ce sont des Mio ...?
Dans ce cas, je crois que je ne peux pas créer 2 partitions de sauvegardes de même taille sur mon dd : il fait 3,64 TiB (4000787030016 octets, 7814037168 secteurs), et si je crée une partition de 1907727 Mio, le reste sur le disque dur est de 1907720 Mio...
Le disque à sauvegarder fait :
2000398934016 octets, 3907029168 secteurs,
tandis que le disque de sauvegarde fait :
4000787030016 octets, 7814037168 secteurs.

À partir de ça, qu'est-il le plus judicieux de faire...?
Désolé pour ces questions probablement bien novices, mais je suis un peu perdu dans ces unités d'octets et secteurs...

Merci beaucoup !

geole

Bonjour
Comme quoi, je ne suis pas doué en calcul mental. Excel confirme ton calcul!
Donc , tu reviens à la première idée.
- Une partition NTFS avec la taille que tu as calculée.
- Une partition EXT4 avec la reste disponible

Puis on lancera la récupération. Lorsqu'on la considérera comme finie, on dupliquera la partition récupérée en compressant pour la stocker sur la seconde partition avant de la fournir à windows pour finaliser la récupération.

Je pense à une codification de ce style

  sudo dcfldd if=/dev/sdX1 bs=4k  conv=notrunc,noerror | gzip -c > ~/master-image.gzip

sudo dd if=/dev/sdX1 bs=4k  conv=notrunc,noerror  status=progress | gzip -c > Un_fichier_dans_la_seconde_partition_master-image.gzip

Mais il y a peut être mieux? http://influence-pc.fr/01-04-2017-ruse-pour-compresser-efficacement-une-image-de-partition-sous-linux

sudo dd if=/dev/sdX1  bs=1M | xz --threads=0 > /media/ubuntu/disque_externe/fichier.xz

https://www.monlinux.net/2014/08/benchmark-compression-gzip-xz-pbzip2/

jamesbad000

Bonjour,

bs=64k est un bon standard pour les disques mécaniques des 10 dernières année. 64M pour des ssd
noerror est une option à éviter, sauf si on a une bonne raison d'accepter une copie foireuse sans même en être informé (et sinon pour un disque à problèmes il faut utiliser ddrescue, pas dd...)
notrunc n'à de sens que si on veut faire un écrasement partiel d'un fichier existant.

Mais bon, si je peux me permettre tout ceci est de la couillonnade, tant que l'image du disque n'a pas été récupérée. Il serait bon de se concentrer sur cette partie délicate... Et je conseille un guidage pas à pas.

Avec tout les disques impliqués connectés, après le retour de

sudo lsblk -o size,name,fstype,label,mountpoint
ls -l /dev/disk/by-id
sudo fdisk -l

ça sera plus facile de voir ou on en est et de préparer la suite

jamesbad000

ps: Si le partitionnement cible n'est pas déjà fait, attendre pour le faire (ca ne sert à rien de formater une partition qu'on va écraser...)

greb

Ok, merci beaucoup.
Du coup, j'aavais formaté entre temps le dd se sauvegarde, avec une grosse partition NTFS de 1.9 Gio, et le reste en ext4.
Les retours des commandes demandées :

~$ sudo lsblk -o size,name,fstype,label,mountpoint[sudo] Mot de passe de benjamin : 
  SIZE NAME   FSTYPE   LABEL      MOUNTPOINT
 89,3M loop0  squashfs            /snap/core/6673
115,8M loop1  squashfs            /snap/carnet/10
 89,4M loop2  squashfs            /snap/core/6818
115,9M loop3  squashfs            /snap/carnet/7
 88,4M loop4  squashfs            /snap/core/6964
232,9G sda                        
232,9G └─sda1 ext4                /
298,1G sdb                        
298,1G └─sdb4 ext4                
  1,8T sdd                        
  1,8T └─sdd1 ntfs     Maxtor     /media/benjamin/Maxtor
  3,7T sde                        
  1,9T ├─sde1 ntfs     sauvegarde /media/benjamin/sauvegarde
  1,7T └─sde2 ext4     ben        /media/benjamin/be

(Maxtor est le dd défectueux, et sauvegarde est la partition NTFS sur le dd de sauvegarde)

~$ ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 juin  15 12:38 ata-SanDisk_SDSSDH3250G_174593421136 -> ../../sda
lrwxrwxrwx 1 root root 10 juin  15 12:38 ata-SanDisk_SDSSDH3250G_174593421136-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 juin  15 12:54 ata-ST4000LM024-2AN17V_WCK3CNMB -> ../../sde
lrwxrwxrwx 1 root root 10 juin  15 12:54 ata-ST4000LM024-2AN17V_WCK3CNMB-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 juin  15 12:54 ata-ST4000LM024-2AN17V_WCK3CNMB-part2 -> ../../sde2
lrwxrwxrwx 1 root root  9 juin  15 12:38 ata-WDC_WD3200BEKT-75PVMT0_WD-WXR1AB0T0012 -> ../../sdb
lrwxrwxrwx 1 root root 10 juin  15 12:38 ata-WDC_WD3200BEKT-75PVMT0_WD-WXR1AB0T0012-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 juin  15 12:54 usb-Seagate_M3_Portable_DFCB7E050500001F-0:0 -> ../../sdd
lrwxrwxrwx 1 root root 10 juin  15 12:54 usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 juin  15 12:54 wwn-0x5000c500be171f66 -> ../../sde
lrwxrwxrwx 1 root root 10 juin  15 12:54 wwn-0x5000c500be171f66-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 juin  15 12:54 wwn-0x5000c500be171f66-part2 -> ../../sde2
lrwxrwxrwx 1 root root  9 juin  15 12:38 wwn-0x50014ee600c7b574 -> ../../sdb
lrwxrwxrwx 1 root root 10 juin  15 12:38 wwn-0x50014ee600c7b574-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 juin  15 12:38 wwn-0x5001b444a9bd6768 -> ../../sda
lrwxrwxrwx 1 root root 10 juin  15 12:38 wwn-0x5001b444a9bd6768-part1 -> ../../sda1

~$ sudo fdisk -l
Disque /dev/loop0 : 89,3 MiB, 93581312 octets, 182776 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop1 : 115,8 MiB, 121450496 octets, 237208 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop2 : 89,4 MiB, 93720576 octets, 183048 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop3 : 115,9 MiB, 121532416 octets, 237368 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/loop4 : 88,4 MiB, 92733440 octets, 181120 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/sda : 232,9 GiB, 250059350016 octets, 488397168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x82227739

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
/dev/sda1    *         2048 488396799 488394752 232,9G 83 Linux


Disque /dev/sdb : 298,1 GiB, 320072933376 octets, 625142448 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x77e3ed41

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
/dev/sdb4              2048 625141759 625139712 298,1G 83 Linux


Disque /dev/sdd : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x54b34f25

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdd1    *           64 3907024064 3907024001   1,8T  7 HPFS/NTFS/exFAT


Disque /dev/sde : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 33553920 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x433ccc41

Périphérique Amorçage      Début        Fin   Secteurs Taille Id Type
/dev/sde1                   2048 4096002047 4096000000   1,9T  7 HPFS/NTFS/exFAT
/dev/sde2             4096002048 7814035455 3718033408   1,7T 83 Linux

jamesbad000

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

Vérifie que tu es d'accord avec les correspondances ci-dessus. A partir de là on va utiliser les identifiants fixe issus de disk/by-id pour éviter toute erreur en cas de changement des lettres de lecteur.
Par la suite il est conseillé de revérifier dans les indications que je donnes qu'il y a bien le bon disque indiqué en source ou en cible !

Il y a presque 100Go de rab sur la partition que tu as créée pour la copie. Je suggère de la refaire avec une taille plus appropriée : en reprenant le nombre de secteurs exact.

sudo parted -s /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB  mklabel msdos
sudo parted -s /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB  mkpart primary 4096s $((3907024001+4096-1))s
sudo parted /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB unit s print

greb

Oui, les disques source et cible sont bien ceux-là.
J'ai fait les commandes :

~$ sudo parted -s /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB  mklabel msdos
~$ sudo parted -s /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB  mkpart primary 4096s $((3907024001+4096-1))s
Avertissement: L'alignement de la partition ainsi définie n'est pas optimal au niveau performance.
~$ sudo parted /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB unit s print
Modèle: LaCie Rugged Mini USB3 (scsi)
Disque /dev/sdc : 7814037168s
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : msdos
Disk Flags: 

Numéro  Début  Fin          Taille       Type     Système de fichiers  Fanions
 1      4096s  3907028096s  3907024001s  primary

jamesbad000

Ok on a une partition qui fait pile la bonne taille (même s'il couine sur l'alignement à cause de la position de fin. Mais en fait elle est bien alignée sur un bloc de 1M (4096 secteurs). Ca implique juste qu'il y aura un espace libre entre celle-ci et la suivante pour que cette dernière soit également bien alignée).

il n'y a plus qu'à lancer la copie avec

sudo ddrescue -f -b 4096 --log-rates=~/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

la partition source étant la première dans la commande...

A partir de là ça devrait tourner éventuellement pendant plusieurs jours. Il ne faut pas s'impatienter. Ni s'inquiéter d'une éventuelle interruption, ddrescue ayant la capacité de reprendre là ou il en était, grace au fichier rescue.map. (suffit de relancer la même commande)
Eventuellement de temps en temps tu peux envoyer une copie du terminal que l'on voit la progression

greb

Ok, merci pour les explications.
J'ai lancé la commande, par contre, j'obtiens une erreur ddrescue... :

~$ sudo ddrescue -f -b 4096 --log-rates=~/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
ddrescue: Can't open file for logging rates: No such file or directory

Y a-t-il quelque chose à créer encore auparavant...?

jamesbad000

Non rien a créer. Mais cette option log-rates avec le ~ m'a déjà posé problème par le passé. De toute façon on peut très bien s'en passer.
Je la met à tout hasard pour pouvoir éventuellement analyser les zones lentes du disque. Mais jusque là je n'ai pas vraiment trouvé le moyen de l'exploiter.
Donc on va pas perdre de temps avec ça :

sudo ddrescue -f -b 4096  /dev/disk/by-id/usb-Seagate_M3_Portable_DFCB7E050500001F-0:0-part1 /dev/disk/by-id/ata-ST4000LM024-2AN17V_WCK3CNMB-part1  ~/rescue.map

geole

Sinon, cela passe avec cette codification

 sudo ddrescue -f -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

jamesbad000

effectivement l'alternative ci-dessus devrait fonctionner. Mais si c'est déjà lancé il n'y a qu'à laisser comme ça

greb

Super, merci à vous deux.
J'ai lancé la commande avec le log enregistré dans mon Home.

Pour l'instant, ça me donne ça :

~$  sudo ddrescue -f -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: 524288 B, tried: 65536 B, bad-sector: 0 B, bad areas: 0

     ipos:   23242 MB, non-trimmed:   22604 MB,  current rate:       0 B/s
     opos:   23242 MB, non-scraped:        0 B,  average rate:   2956 kB/s
non-tried:    1977 GB,  bad-sector:        0 B,    error rate:    274 MB/s
  rescued:  644968 kB,   bad areas:        0,        run time:      3m 38s
pct rescued:    0.03%, read errors:   345015,  remaining time:         n/a
                              time since last successful read:      2m  4s
Copying non-tried blocks... Pass 5 (forwards)

J'enverrai de temps en temps l'évolution.

jamesbad000

Déjà sur la pass 5 ! Et le error rate à 274 Mb/s laisse a penser qu'il a "survolé" le disque en sautant de gros blocs pour essayer de trouver des zones lisibles facilement, et n'en a pas trouvé... du coup il est rentré directement dans le dur, et ça va probablement être très long...

greb

Effectivement, ça semble parti pour être très long...

Point avancement :

~$  sudo ddrescue -f -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: 524288 B, tried: 65536 B, bad-sector: 0 B, bad areas: 0

     ipos:   11028 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:   11028 MB, non-scraped:    1989 GB,  average rate:    336 kB/s
non-tried:        0 B,  bad-sector:    5943 MB,    error rate:  18288 kB/s
  rescued:    5228 MB,   bad areas:       13,        run time:  4h 18m 49s
pct rescued:    0.26%, read errors: 31962849,  remaining time:         n/a
                              time since last successful read:      4m  8s
Scraping failed blocks... (forwards)

(j'ai vu passer des moments avec un error rate à 0, et un remaining time à 3-4 jours)

greb

Un nouveau point avancement :

~$  sudo ddrescue -f -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: 524288 B, tried: 65536 B, bad-sector: 0 B, bad areas: 0

     ipos:  823101 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:  823101 MB, non-scraped:    1177 GB,  average rate:    517 kB/s
non-tried:        0 B,  bad-sector:  764151 MB,    error rate:  19472 kB/s
  rescued:   59093 MB,   bad areas:       27,        run time:  1d  7h 42m
pct rescued:    2.95%, read errors:217072202,  remaining time:         n/a
                              time since last successful read:  3h  6m 11s
Scraping failed blocks... (forwards)

Par contre, malencontreusement, le câble du dd cible s'est débranché... lorsque j'ai bougé l'ordinateur et les dd. J'ai vu que ddrescue continuait de tourner, et j'ai rebranché le câble. Ça a continué de tourner, et rien n'a semblé être perturbé...
Mais est-ce un problème...?
Concrètement, que se passe-t-il sur le disque cible, lorsque ddrescue tourne ?

Et vus les résultats pour l'instant (2.95% du total qui sont rescued - toujours pareil 1h après la copie ci-dessus), est-ce que ça vaut vraiment le coup de continuer...? Combien de temps encore l'ensemble des manips pour aller jusqu'à une potentielle récupération de quelques % est à envisager ...?

geole

Bonsoir
Si le câble du disque entrée est débranché, il n'a pas pu lire les secteurs. Normalement, il les a encore en "liste d'attente' pour les passages de récupération.
Si le câble du disque sortie est débranché, il y aurait du avoir une erreur de signalée. S'il n'y a pas eu d'erreur c'est probablement que le rebranchement s'est fait très rapidement après le débranchement et que, à sa Nieme tentative d'écriture avant de dire qu'il ne pouvait pas écrire, c'est redevenu bon

Si je ne me trompe pas, il a déjà traité 823 Go dont 764 Go n'ont pas pu être transtérés... La suite sera dure.... Je crains qu'il faudra plutôt cibler "photorec" que la remise en état de la partition. Voici de quoi lire pendant la semaine https://doc.ubuntu-fr.org/photorec

Le plus embêtant c'est cela time since last successful read: 3h 6m 11s
En fait, pendant trois heures et six minutes, le câble du disque sortie aurait pu être débranché sans risque puisque rien n'était proposé en écriture

Je propose que tu le laisses aller jusqu'à fin du disque. Tu es presque à la moitié. La seconde partie peut être de meilleure qualité.

« Page précédente Page suivante »