DDRESCUE pour tentative de copie dique à disque

rmy · Le 27/10/2019, à 01:50

Désolé d'insister mais… as tu la possibilité de mettre ton disque hors boitier, en sata, dans une tour ?

SIEG · Le 30/10/2019, à 18:51

@rmy : non désolé.

@geole : j'ai posté dans mon dernier message les rendus de tes commandes. Dois-je tenter la commande de récupération que tu m'as transmise ?

sudo ddrescue    -v    -b4096  -K524288  --idirect    --log-events=/media/dudu/SPIKE/events.log    /dev/sde  /media/dudu/SPIKE/3To.img   /media/dudu/SPIKE/3to.log

@moko138 : Puis-je avoir ton retour sur le rendu de ta commande ?

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

lsusb | sort; echo; lsusb -t
Bus 001 Device 003: ID 0bc2:3320 Seagate RSS LLC SRD00F2 [Expansion Desktop Drive]

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 1: Dev 2, (...)
    |__ Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Montre le retour, quel qu'il soit, de :

sudo smartctl -s on -S on -o off -d sat -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)

- -

Par ailleurs, rmy a évoqué

la possibilité de mettre ton disque hors boitier, en sata, dans une tour

Puisque tu ne peux pas le faire chez toi, débrouille-toi pour y parvenir chez un copain/voisin/au boulot/etc.

Dernière modification par moko138 (Le 30/10/2019, à 19:44)

geole · Le 30/10/2019, à 19:57

Bonjour SIEG
Toutes les pistes tournent autour du fait que la connectique en amont du disque n'est pas excellante,
Si cette connectique change, Il est possible que le disque devienne nickel
Si cette connectique ne change pas, il est possible que seulement 1% des données soit copié.
Il est même possible que cette connectique casse pendant la duplication

NOTA. Tu peux aussi acheter un autre boitier d'une marque différente. Certains peuvent fonctionner une semaine sans incident mais pas tous.

moko138 · Le 30/10/2019, à 20:05

Avant d'acheter un nouveau boîtier, il convient d'ouvrir celui du Seagate.
Parce que si l'intérieur se présente comme ceci :
(interface usb soudée),
alors c'est râpé pour le changement d'interface. (Sauf, peut-être, pour un professionnel équipé ?)

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

moko138 a écrit :

Avant d'acheter un nouveau boîtier, il convient d'ouvrir celui du Seagate.
Parce que si l'intérieur se présente comme ceci :
http://pix.tdct.org/upload/img/1438433839.jpg (interface usb soudée),
alors c'est râpé pour le changement d'interface. (Sauf, peut-être, pour un professionnel équipé ?)

Non Moko, c'est un ST3000DM001-1E6166, un SATA 3"5, pas de connectique USB soudée sur la PCB avec ça…

SIEG · Le 31/10/2019, à 15:26

Salut tout le monde.

@moko138

voici le résultat de ta commande :

sudo smartctl -s on -S on -o off -d sat -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)

sudo smartctl -s on -S on -o off -d sat -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.0.0-32-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Read Device Identity failed: Inappropriate ioctl for device

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

...

moko138 · Le 31/10/2019, à 16:14

Merci !

Le cas échéant, fais comme en #25 :

SIEG a écrit :

J'ai attendu que la Led cesse de clignoter (un quart d'heure) et j'ai relancé la commande

et essaie cette variante :

sudo smartctl -d sat -s on -S on -o off -T verypermissive -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)

et

sudo smartctl  -s on -S on -o off -T verypermissive -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)

Mais, comme "-d sat" est correct, il me semble que "Inappropriate ioctl" désigne l'interface comme HS.
As-tu essayé un autre câble (usb2, par exemple) ?

SIEG · Le 05/11/2019, à 13:33

Bonjour tout le monde.

@moko138

- J'ai retenté ta première commande, même résultat

- Ensuite :

sudo smartctl -d sat -s on -S on -o off -T verypermissive -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)


Read Device Identity failed: Inappropriate ioctl for device

=== START OF INFORMATION SECTION ===
Device Model:     [No Information Found]
Serial Number:    [No Information Found]
Firmware Version: [No Information Found]
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   [No Information Found]
Local Time is:    Tue Nov  5 05:52:08 2019 CET
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 82-83 don't show if SMART supported.
SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 85-87 don't show if SMART is enabled.
                  Checking to be sure by trying SMART RETURN STATUS command.
SMART support is: Unknown - Try option -s with argument 'on' to enable it.
=== START OF ENABLE/DISABLE COMMANDS SECTION ===
SMART Enable failed: Inappropriate ioctl for device

SMART Enable Attribute Autosave failed: Inappropriate ioctl for device

Read SMART Data failed: Inappropriate ioctl for device

SMART Automatic Timers not supported

SMART Disable Automatic Offline failed: Inappropriate ioctl for device


=== START OF READ SMART DATA SECTION ===
SMART Status command failed: Inappropriate ioctl for device
SMART overall-health self-assessment test result: UNKNOWN!
SMART Status, Attributes and Thresholds cannot be read.

Read SMART Error Log failed: Inappropriate ioctl for device

Read SMART Self-test Log failed: Inappropriate ioctl for device

Selective Self-tests/Logging not supported

- Et :

sudo smartctl  -s on -S on -o off -T verypermissive -a /dev/disk/by-id/$(ls -l /dev/disk/by-id | grep -Ev "part|Reader|sr" | awk '{print $9}' | grep -i usb-S)

/dev/disk/by-id/: Unable to detect device type
Please specify device type with the -d option.

Use smartctl -h to get a usage summary

Cela n'a pas l'air très encourageant. Puis-je tenter une restauration ?

geole · Le 05/11/2019, à 14:49

Bonjour.
J'ai bien l'impression qu'il sera impossible de connaitre l'état du disque.

Si tu as des données super importantes, contacte RMY
Sinon, tentes la duplication. Mais aucune idée du résultat.

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

moko138 · Le 05/11/2019, à 17:51

Si un changement de câble (même usb2) ne donne rien,
soit tu appliques la fin du #28
soit, comme dit geole, tu contactes rmy directement.

SIEG · Le 05/11/2019, à 23:49

@geole

Je tente ta commande en #24 ?

sudo ddrescue    -v    -b4096  -K524288  --idirect    --log-events=/media/dudu/SPIKE/events.log    /dev/sde  /media/dudu/SPIKE/3To.img   /media/dudu/SPIKE/3to.log

ps : Il y a un système de messages privés sur ce forum pour contacter des membres ?

Nasman · Le 06/11/2019, à 09:01

Tu vas sur le profil du membre à contacter (en cliquant sur son pseudo) et tu cliques sur "envoyer un e-mail" (fonctionnera si le membre a renseigné une adresse mail - invisible dans le profil).

nany · Le 06/11/2019, à 09:15

Bonjour,

Si c’est pour contacter rmy, il y a aussi ce formulaire.

geole · Le 06/11/2019, à 14:59

SIEG a écrit :

@geole

Je tente ta commande en #24 ?

sudo ddrescue    -v    -b4096  -K524288  --idirect    --log-events=/media/dudu/SPIKE/events.log    /dev/sde  /media/dudu/SPIKE/3To.img   /media/dudu/SPIKE/3to.log

Bonjour.
Tu peux tenter la commande.
Si au bout d'un quart d'heure, tu constates que l'écran de suivi indique que rien a été copié, il sera inutile d'insister.
Sinon, tu peux publier un état de l'avancement de la duplication en ouvrant une autre session et en frappant cette commande:

ddrescuelog  -tvv  /media/dudu/SPIKE/3to.log

Dernière modification par geole (Le 06/11/2019, à 15:00)

rmy · Le 09/11/2019, à 09:46

@Sieg, est-ce que ça avance ?

SIEG · Le 13/11/2019, à 19:14

Bonjour à tous. Voici des nouvelles.

current pos:  237414 MB,  current status: copying
mapfile extent:    3000 GB,  in   3598 area(s)

     non-tried:    2764 GB,  in   1308 area(s)  ( 92.12%)
       rescued:  236248 MB,  in    983 area(s)  (  7.87%)
   non-trimmed:   85655 kB,  in   1307 area(s)  (  0.00%)
   non-scraped:        0 B,  in      0 area(s)  (  0%)
    bad-sector:        0 B,  in      0 area(s)  (  0%)

Cela va bientôt faire 2 jours que j'ai lancé la restauration et on est à peine à 10% donc c'est très très long mais cela semble fonctionner. Comme à ce rhytme là j'en ai pour 3 semaines, j'ai quelques questions.

@Geole

- La session de travaille indique "Pass 1 (forwards)" : Y a t'il d'autres pass de prévues à la fin ?

- Comme je redoute une coupure d'électricité entre temps; existe-t-il un moyen ou une commande pour "sauvegarder la copie" dans le sens ou si cela coupe, que je ne sois pas obligé de tout recommencer ?

- Le fichier .img est bien là. Quand il sera complet, que devrais-je faire pour accéder aux données pour les récupérer ?

Merci à tous pour le temps consacré ,)

rmy · Le 13/11/2019, à 20:04

Le fichier log est là exprè spour pouvoir reprendre là où tu t'es arrêté en cas de coupure ou arrêt volontaire.
Ton disque est en très mauvais état et ta vitesse moyenne de copie est de l'ordre de 1Mo par seconde, donc bien moins que l'éventuel facteur limitant lié à l'USB. Quel était le taux de remplissage de ce disque ?

Oui il y a d'autre pass à la fin.

Quand ton image sera complète, on pourra essayer d'accéder à son contenu avec testdisk pa exemple. Il vaut toujours mieux travailler sur un support sain ;-)

SIEG · Le 13/11/2019, à 20:44

Salut rmy.

- Pour le fichier .log, c'est une bonne nouvelle. Quand il va y avoir une coupure (ce qui ne manquera pas d'arriver vu la lenteur), aurais-je juste à relancer la même commande de départ pour que cela reprenne ?

- Pour les pass, sais-tu combien il y en a de prévues et sont-elles du même ordre temporel (c'est à dire vont-elles prendre autant de temps proportionnellement à la première pass)

- Le disque était presque plein de mémoire

Merci

Dernière modification par SIEG (Le 13/11/2019, à 20:50)

geole · Le 13/11/2019, à 22:50

Bonsoir.
Cela avance cahin-caha.
Normalement le premier passage est ultra rapide puisqu'il ne lit que les zones en bon état.
Mais, dans ton contexte, il y a un autre problème lié au transfert des données dont on n'a pas trouvé la raison. Il ralentit considérablement ce passage.

Il me semble qu'il y a cinq passes. ( passe actuelle puis 2 Passes trimmed puis 2 passes scrapped) Chaque passe traite les données qui ont été mises de coté au passage précédant. Normalement, il y a de moins en moins de données. Mais le temps de lecture d'un secteur illisible est probablement de l'ordre d'une minute au lieu de trente millisecondes.

Si , pour une raison quelconque, le process est stoppé,
tu peux le relancer avec exactement la même commande.
A son démarrage, il consultera le fichier log pour savoir ce qui a déjà été traité, Ce fichier log est mis régulièrement à jour ( probablement toutes les minutes).

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

SIEG · Le 15/01/2020, à 02:05

Salut tout le monde.

Je vous souhaite à tous une bonne et heureuse année, pleine de bonnes choses pour vous ; la santé surtout.

Je vous tiens quand même au courant de mon histoire qui n’est pas terminée ; hélas.

Après plusieurs semaines de procédures fastidieuses, (avec quelques coupures et temps de repos), j’ai récupéré une image à 75%. A partir de là, (nous étions en pass 5) la récupération a encore ralenti pour représenter un gain d’environ 0.10 % par jour.

Au stade où j’en étais ce n’était plus vraiment le temps le problème mais suite à une coupure de courant, j’ai relancé la procédure qui à mon grand étonnement a recommencé au début – c’est à dire à 0% - alors que d’ordinaire, elle reprenait là où elle s’était arrêtée. J’ai relancé l’opération plusieurs fois; sans succès.

Cherchant à comprendre, j’ai remarqué un changement étrange qui ne semble pas de mon fait mais le chemin de mon disque de récupération (sdc2) à savoir « /media/dudu/SPIKE » est devenu « /media/dudu/SPIKE1 »

Je ne sais pas si cela change quelque chose sachant que le disque que j’essaie de sauver (à savoir sde) s’appelait lui aussi SPIKE à l’origine mais son nom n’est plus reconnu depuis longtemps

sudo lsblk -o name,fstype,size,label,mountpoint,uuid
[sudo] Mot de passe de dudu : 
NAME   FSTYPE   SIZE LABEL       MOUNTPOINT UUID
loop0  squash  14,8M             /snap/gnom 
loop1  squash 156,7M             /snap/gnom 
loop2  squash  42,8M             /snap/gtk- 
loop3  squash  44,2M             /snap/gtk- 
loop4  squash   3,7M             /snap/gnom 
loop5  squash 202,9M             /snap/vlc/ 
loop6  squash  79,6M             /snap/matr 
loop7  squash  54,6M             /snap/core 
loop8  squash   3,7M             /snap/gnom 
loop9  squash   4,2M             /snap/gnom 
loop10 squash  54,6M             /snap/core 
loop11 squash   956K             /snap/gnom 
loop12 squash   4,2M             /snap/gnom 
loop13 squash  14,8M             /snap/gnom 
loop14 squash   156M             /snap/gnom 
loop15 squash  1008K             /snap/gnom 
loop16 squash  89,1M             /snap/core 
loop17 squash 202,9M             /snap/vlc/ 
loop18 squash  89,1M             /snap/core 
sda            74,5G                        
└─sda1 ntfs    74,5G CAMUS                  10F002F5F002E138
sdb           298,1G                        
├─sdb1 ntfs   249,3G MILO                   6250092D5009098D
└─sdb2 ext4    48,9G             /          b04d318d-37dc-4963-8b9c-f6d6fd722eb0
sdc             7,3T                        
├─sdc1 ntfs       4T JACK        /media/dud AE6E17466E1706AD
└─sdc2 ntfs     3,3T SPIKE       /media/dud B2B6D836B6D7F935
sdd            14,5G                        
└─sdd1 vfat    14,5G UBUNTU 18_0 /media/dud D0D2-BF8B
sde             2,7T                        
sr0            1024M

- Y a t’il un possible conflit ?
- Que me suggérez-vous les gars dans cette situation, dois-je tenter d’accéder à mon image incomplète ?

Comme vous le voyez, l’année commence bien

Encore merci à vous.

geole · Le 17/01/2020, à 13:12

Bonjour
C'était trop beau pour qu'en une période si longue, Il n'y ait pas eu une fausse manipulation.
D'après ce que tu dis, c'est la coupure de courant qui a modifié les points de montage.
J'ai retrouvé la commande initiale

sudo ddrescue    -v    -b4096  -K524288  --idirect    --log-events=/media/dudu/SPIKE/events.log    /dev/sde  /media/dudu/SPIKE/3To.img   /media/dudu/SPIKE/3to.log

Si tu sais que le disque d'écriture (SDC ???) se monte maintenant sur SPIKE1 au lieu de SPIKE, il suffit que tu modifies la commande pour qu'elle devienne

sudo ddrescue    -v    -b4096  -K524288  --idirect    --log-events=/media/dudu/SPIKE1/events.log    /dev/sde  /media/dudu/SPIKE1/3To.img   /media/dudu/SPIKE1/3to.log

Si les deux partitions ( La grosse partition de récupération de données et la partition contenant le log ) sont bien montées sur SPIKE1

Je mémorise qu'il aurait été mieux de travailler avec des UUID et de prendre en charge le montage manuel des partitions de sorties sur des points de montage dédiés

AJOUT
Pour le nom des disques ( cas de SDE) c'est la commande

ls -ls /dev/disk/by-id | grep -v part

Dernière modification par geole (Le 17/01/2020, à 15:24)

moko138 · Le 17/01/2020, à 14:53

sudo lsblk -o name,fstype,size,label,mountpoint,uuid
engendre :

a) Une liste interminable de snap dont on n'a rien à faire. Donc pensez à
/!\ finir la ligne par | grep -v snap

b) Des points de montage INCOMPLETS, car coupés pour faire place aux uuid :

NAME FSTYPE SIZE LABEL MOUNTPOINT UUID
sda 74,5G
└─sda1 ntfs 74,5G CAMUS 10F002F5F002E138
sdb 298,1G
├─sdb1 ntfs 249,3G MILO 6250092D5009098D
└─sdb2 ext4 48,9G / b04d318d-37dc-4963-8b9c-f6d6fd722eb0
sdc 7,3T
├─sdc1 ntfs 4T JACK /media/dud AE6E17466E1706AD
└─sdc2 ntfs 3,3T SPIKE /media/dud B2B6D836B6D7F935
sdd 14,5G
└─sdd1 vfat 14,5G UBUNTU 18_0 /media/dud D0D2-BF8B
sde 2,7T

Remède : demander l'uuid avant "label,mountpoint".
.

Donc
pour obtenir un retour exploitable, ressemblant à :

NAME    FSTYPE    SIZE UUID                                 LABEL             MOUNTPOINT
├─sdc1  ext4      421G 12345678-abcd-1234-abcd-1234567890ab CHOSE-TRUC       /media/moi/CHOSE-TRUC

/!\ Aidants et aidés, notez dans vos tablettes la commande exploitable :

sudo lsblk -o name,fstype,size,uuid,label,mountpoint | grep -v snap

Merci !

SIEG · Le 14/02/2020, à 01:13

Bonjour à tous.

Après plusieurs tentatives, la progression est de plus en plus lente : 0.01% par jour. Je pense que je ne récupérerai pas une image complète à 100%.

Que me conseillez-vous dans cette situation ? Dois-je tenter d'accéder aux données avec un scan disk ?

rmy · Le 14/02/2020, à 01:15

Tu n'auras jamais une image à 100%, c'était annoncé dès le départ vu le nombre de secteurs HS.
Qu'est-ce que tu appelles un scan disk ?
Ne fais rien qui puisse écrire ou modifier ton image sans avoir au préalable, comme la fois précédente, fait une copie secondaire de l'état conservé.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 27/10/2019, à 01:50

Re : DDRESCUE pour tentative de copie dique à disque

#27 Le 30/10/2019, à 18:51

Re : DDRESCUE pour tentative de copie dique à disque

#28 Le 30/10/2019, à 19:42

Re : DDRESCUE pour tentative de copie dique à disque

#29 Le 30/10/2019, à 19:57

Re : DDRESCUE pour tentative de copie dique à disque

#30 Le 30/10/2019, à 20:05

Re : DDRESCUE pour tentative de copie dique à disque

#31 Le 31/10/2019, à 09:21

Re : DDRESCUE pour tentative de copie dique à disque

#32 Le 31/10/2019, à 15:26

Re : DDRESCUE pour tentative de copie dique à disque

#33 Le 31/10/2019, à 16:14

Re : DDRESCUE pour tentative de copie dique à disque

#34 Le 05/11/2019, à 13:33

Re : DDRESCUE pour tentative de copie dique à disque

#35 Le 05/11/2019, à 14:49

Re : DDRESCUE pour tentative de copie dique à disque

#36 Le 05/11/2019, à 17:51

Re : DDRESCUE pour tentative de copie dique à disque

#37 Le 05/11/2019, à 23:49

Re : DDRESCUE pour tentative de copie dique à disque

#38 Le 06/11/2019, à 09:01

Re : DDRESCUE pour tentative de copie dique à disque

#39 Le 06/11/2019, à 09:15

Re : DDRESCUE pour tentative de copie dique à disque

#40 Le 06/11/2019, à 14:59

Re : DDRESCUE pour tentative de copie dique à disque

#41 Le 09/11/2019, à 09:46

Re : DDRESCUE pour tentative de copie dique à disque

#42 Le 13/11/2019, à 19:14

Re : DDRESCUE pour tentative de copie dique à disque

#43 Le 13/11/2019, à 20:04

Re : DDRESCUE pour tentative de copie dique à disque

#44 Le 13/11/2019, à 20:44

Re : DDRESCUE pour tentative de copie dique à disque

#45 Le 13/11/2019, à 22:50

Re : DDRESCUE pour tentative de copie dique à disque

#46 Le 15/01/2020, à 02:05

Re : DDRESCUE pour tentative de copie dique à disque

#47 Le 17/01/2020, à 13:12

Re : DDRESCUE pour tentative de copie dique à disque

#48 Le 17/01/2020, à 14:53

Re : DDRESCUE pour tentative de copie dique à disque

#49 Le 14/02/2020, à 01:13

Re : DDRESCUE pour tentative de copie dique à disque

#50 Le 14/02/2020, à 01:15

Re : DDRESCUE pour tentative de copie dique à disque

Pied de page des forums