Existe-t-il un moyen d'accélérer le retrait?

J'ai eu un crash de disque dur de 500 Go il y a environ 5 jours. J'ai utilisé ddrescuesur la partition importante il y a quelques jours, et cela fait maintenant près de 2 jours que "Couper les blocs en panne".

Commande d'origine:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

Sortie courant:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

La commande d'origine a utilisé le ddrescue -nparamètre, et j'ai redémarré le processus plusieurs fois au besoin (et il semblait reprendre là où il s'était arrêté à chaque fois).

Existe-t-il un moyen d'accélérer ce processus?

Edit: Six heures plus tard, voici l'état actuel:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

Il semble que, bien que les «erreurs» décomptent lentement, les ipos / opos décomptent la quantité de données à parcourir, et il semble fonctionner à un taux de 750 Mo / heure. À ce rythme, il se terminera en ~ 53 heures. Oui.

Edit # 2: Deux jours plus tard, toujours en cours d'exécution. Cependant, il y a de l'espoir. Il a dépassé la partie "Découpage des blocs défaillants" et passe à la phase suivante "Fractionnement des blocs défaillants". Si quoi que ce soit, ce qui devrait être retiré de l'affichage de cette question, c'est que cela prend certainement beaucoup de temps lorsqu'une bonne quantité de données / erreurs sont impliquées. Mon seul espoir est que je puisse récupérer avec succès certaines données importantes quand tout sera dit et fait.

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

J'ai observé que l'utilisation de l' -noption (sans fractionnement) avec -r 1(réessayer une fois) et le réglage -c(taille du cluster) sur une valeur plus petite peut aider.

Mon impression est que l'étape de fractionnement est très lente car elle ddrescuese fractionne et fractionne à nouveau les zones endommagées. Cela prend beaucoup de temps car il ddrescuetente de restaurer de très petites portions de données. , Je préfère utiliser ainsi -n(sans séparation) avec -c 64, -c 32, -c 16, aso

Probablement le -n(sans division) devrait toujours être utilisé pour un premier passage dans les directions avant et arrière. Il semble que plus les données ont été divisées, plus le clonage est lent, bien que je n'en sois pas sûr. Je suppose que plus les zones non traitées sont grandes, mieux lors de la réexécution ddrescue, car des secteurs plus contigus doivent être clonés.

Comme j'utilise un fichier journal, je n'hésite pas à annuler la commande avec Ctrl+ Clorsque la vitesse de lecture des données devient deux faible.

J'utilise également le -Rmode (Inverse) et après un premier passage, cela me donne souvent des vitesses plus élevées de lecture en arrière qu'en avant.

Pour moi, la façon dont les secteurs déjà essayés ( -r N) sont traités lors de la réexécution de la ddrescuecommande n'est pas claire , en particulier lors de l'alternance -Rdes commandes de clonage avant (par défaut) et inverse ( ). Je ne sais pas si le nombre de fois où ils ont été essayés est stocké dans le fichier journal et probablement le travail est à nouveau inutile.

Le -idrapeau (position d'entrée) peut également aider à accélérer les choses.

Il peut être très difficile de voir la progression de ddrescue, mais une autre commande incluse est appelée ddrescuelog.

Une simple commande ddrescuelog -t YourLog.txtaffichera ces belles infos:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

Vous pouvez même l'utiliser en ddrescuecours d'exécution ...

Une autre façon de surveiller les progrès de ddrescue (sous Linux, au moins) consiste à utiliser strace.

Tout d'abord, recherchez le PID du processus ddrescue à l'aide de "ps aux | grep ddrescue"

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

Exécutez ensuite "strace" contre ce processus. Vous verrez quelque chose comme:

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C

...etc. La sortie est rapide et moche, donc je la passe ensuite par "grep" pour filtrer les choses qui m'intéressent:

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

Dans cet exemple, le "1702212676608" équivaut à "la quantité de données qui doit encore être traitée sur ce disque de 2 To que vous essayez de récupérer". (Ouais. Aïe.) Ddrescue crache un nombre similaire - bien que "1720 Go" - dans sa sortie d'écran.

strace vous offre un flux de données BEAUCOUP de granularité à examiner; c'est une autre façon d'évaluer la vitesse de ddrescue et d'estimer une date d'achèvement.

Le faire fonctionner en permanence est probablement un mauvais plan car il rivaliserait avec ddrescue pour le temps CPU. J'ai pris l'habitude de la diriger vers la "tête" pour que je puisse saisir les 10 premières valeurs:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

J'espère que cela aide quelqu'un.

Si votre objectif est d'obtenir la majeure partie des données intactes, vous pouvez accélérer leur extraction. Mais si vous voulez vraiment récupérer autant de données que possible, alors laisser ddrecue grignoter à chaque fois est la route à suivre.

J'ai trouvé qu'en jouant avec le paramètre -K, vous pouvez accélérer les choses. D'après ce que j'ai vu si ddrescue trouve une erreur lors de l'exécution avec l'option -n tente de sauter une quantité fixe de secteurs. S'il ne sait toujours pas lire, il double sa taille. Si vous avez de grandes zones endommagées, vous pouvez indiquer une grande valeur K (par exemple 100M) et ainsi le saut sur une erreur sera plus grand la première fois et il sera plus facile d'éviter rapidement les zones problématiques dans le premier passé.

Soit dit en passant, il existe une merveilleuse application graphique pour analyser le journal.

http://sourceforge.net/projects/ddrescueview/

Quel est le système de fichiers du disque dur sur lequel vous enregistrez l'image de secours et le fichier journal? Je viens de faire l'expérience que le sauvetage d'un disque dur interne de 500 Go (connecté via SATA) sur un ordinateur portable exécutant Linux Mint à partir d'une clé USB, en enregistrant l'image de secours et le fichier journal sur un exFatdisque dur USB formaté, commençait assez lentement (1-2 Mo / sec) mais après environ 250 Go, il ne rampait qu'à <100 Ko / sec. Il semblait devenir plus lent à mesure que le fichier image de secours augmentait.

J'ai ensuite déplacé l'image de secours et le fichier journal vers un autre emplacement temporaire, reformaté le disque dur USB avec le ext4système de fichiers, déplacé les fichiers dessus et repris le processus ddrescue - et maintenant il fonctionne à nouveau avec 1-20 Mo / sec (fluctuant mais environ 7 Mo / sec en moyenne)!

On dirait exFatque ne joue pas très bien avec de très gros fichiers (plusieurs centaines de gigaoctets).

Pour une option plus rapide et rapide pour sauver le disque, vous pouvez utiliser un fichier de script sh et exécuter le fichier avec "sh filename.sh". Il contient cette ligne montrée, répétez simplement "sudo ddrescue" et "sleep 3" encore quelques fois, le sommeil est utilisé pour faire reposer le lecteur quelques secondes, cela peut être bon pour certaines raisons:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

Le -r0 est sans réponses. Le -e +0 correspond à la sortie sur 1 erreur. Le -T 1s se termine avec 1 seconde de lecture en échec. Il existe des options qui peuvent être utilisées comme -d pour direct et -n pour pas de raclage, ce qui peut accélérer.

Vous pouvez utiliser -R après la fin avec l'option -A une fois, qui inversera et supprimera toutes les erreurs et recommencera à l'envers. Signifie qu'il lira les erreurs différemment.

dd_rhelp est un script shell qui utilise dd_rescue "[...] sur tout votre disque, MAIS il essaiera de rassembler le maximum de données valides avant d'essayer pendant des siècles sur des grappes de secteurs défectueux"

il est assez ancien (2012) mais fonctionne toujours. n'ont pas encore essayé ddrescue.