C'è un modo per accelerare ddrescue?

Ho avuto un crash del disco rigido da 500 GB circa 5 giorni fa. L'ho usato ddrescuesull'importante partizione alcuni giorni fa ed è stato in "Taglio blocchi non riusciti" per quasi 2 giorni.

Comando originale:

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

Uscita corrente:

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...

Il comando originale ha utilizzato il ddrescue -nparametro e ho riavviato il processo alcune volte in base alle esigenze (e sembrava riprendersi esattamente da dove si era interrotto ogni volta).

C'è un modo per accelerare questo processo?

Modifica: sei ore dopo, questo è lo stato corrente:

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...

Sembra che mentre gli "errori" stiano eseguendo il conto alla rovescia in modo lancinante lentamente, ipos / opos sta contando il numero di dati che devono sfornare e sembra funzionare a una velocità di 750 MB / ora. A questo ritmo, verrà completato in ~ 53 ore. Yikes.

Modifica n. 2: due giorni dopo, ancora in esecuzione. Tuttavia, c'è speranza. È stato spostato oltre la parte "Taglio blocchi non riusciti" e alla fase successiva "Divisione dei blocchi guasti". Semmai, ciò che dovrebbe essere tolto dalla visualizzazione di questa domanda è che ciò richiede sicuramente molto tempo quando è coinvolta una buona quantità di dati / errori. La mia unica speranza è che posso recuperare con successo alcuni dati importanti quando tutto è stato detto e fatto.

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...

Ho osservato che può essere utile utilizzare l' -nopzione (senza divisione) insieme a -r 1(riprovare una volta) e impostare -c(dimensione del cluster) su un valore inferiore.

La mia impressione è che il passaggio di divisione sia molto lento poiché si ddrescuedivide e divide nuovamente le aree danneggiate. Questo richiede molto tempo perché ddrescuetenta di ripristinare porzioni di dati molto piccole. Quindi, io preferisco usare -n(no-split) insieme a -c 64, -c 32, -c 16, etc.

Probabilmente il -n(no-split) dovrebbe sempre essere usato per un primo passaggio nelle direzioni avanti e indietro. Sembra che più i dati sono stati divisi, più lenta è la clonazione, anche se non ne sono sicuro. Immagino che più grandi siano le aree non trattate, le migliori quando si corre di ddrescuenuovo, perché settori più contigui devono essere clonati.

Mentre sto usando un file di registro, non esito a cancellare il comando con Ctrl+ Cquando la velocità di lettura dei dati diventa due bassa.

Uso anche la -Rmodalità (Reverse) e dopo un primo passaggio spesso mi dà una velocità maggiore leggendo all'indietro che in avanti.

Non mi è chiaro come -r Nvengano gestiti i settori già provati ( ) quando si esegue di ddrescuenuovo il comando, in particolare quando si alternano i -Rcomandi di clonazione in avanti (impostazione predefinita) e inversa ( ). Non sono sicuro se il numero di volte in cui sono stati provati è memorizzato nel file di registro e probabilmente il lavoro viene ripetuto inutilmente.

Probabilmente anche il -iflag (posizione di input) può aiutare ad accelerare le cose.

Può essere molto difficile vedere l'avanzamento di ddrescue, ma c'è un altro comando incluso chiamato ddrescuelog.

Un semplice comando ddrescuelog -t YourLog.txtprodurrà queste belle informazioni:

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%)

Puoi persino usarlo mentre ddrescueè in esecuzione ...

Un altro modo per monitorare i progressi di ddrescue (almeno su Linux) è attraverso l'uso di strace.

Innanzitutto, trova il PID per il processo ddrescue usando "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

Quindi eseguire "strace" contro quel processo. Vedrai qualcosa del tipo:

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

...e così via. L'output è veloce e brutto, quindi lo installo attraverso "grep" per filtrare le cose a cui tengo:

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

In questo esempio, "1702212676608" equivale a "la quantità di dati che devono ancora essere elaborati su quel disco da 2 Tb che stai tentando di recuperare". (Sì. Ouch.) Ddrescue sta emettendo un numero simile - anche se come "1720 GB" - nella sua uscita sullo schermo.

strace offre un flusso di dati di granularità MOLTO più elevato da esaminare; è un altro modo per valutare la velocità di ddrescue e stimare una data di completamento.

Eseguirlo costantemente è probabilmente un cattivo piano poiché competerebbe con ddrescue per il tempo della CPU. Ho preso il piping per "testa" in modo da poter prendere i primi 10 valori:

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

Spero che questo aiuti qualcuno.

Se il tuo obiettivo è quello di ottenere la maggior parte dei dati intatti, puoi accelerarne l'estrazione. Ma se vuoi veramente salvare quanti più dati possibili, allora lasciare che ddrecue stia sgranocchiando ogni singolo percorso.

Ho scoperto che giocando con il parametro -K puoi velocizzare le cose. Da quello che ho visto se ddrescue trova un errore durante l'esecuzione con l'opzione -n ​​tenta di saltare una quantità fissa di settori. Se ancora non riesce a leggere, salta il doppio della dimensione. Se hai aree danneggiate di grandi dimensioni, puoi indicare un valore K elevato (ad esempio 100 M) e quindi il salto su un errore sarà più grande la prima volta e sarà più facile evitare rapidamente aree problematiche nel primo passato.

A proposito, c'è una meravigliosa applicazione grafica per analizzare il registro.

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

Qual è il file system del disco rigido in cui si salva l'immagine di ripristino e il file di registro? Ho appena fatto l'esperienza che il salvataggio di un disco rigido interno da 500 GB (collegato tramite SATA) su un laptop che esegue Linux Mint da una chiavetta USB, salvando l'immagine di salvataggio e il file di log su un exFatdisco rigido USB formattato, iniziava piuttosto lentamente (1-2 MB / sec) ma dopo circa 250 GB stava solo strisciando a <100 KB / sec. Sembrava rallentare quanto più cresceva il file di immagine di salvataggio.

Quindi ho spostato l'immagine di salvataggio e il file di registro in un altro posto temporaneo, ho riformattato il disco rigido USB con il ext4file system, ho spostato i file su di esso e ho ripreso il processo ddrescue - e ora funziona di nuovo con 1-20 MB / sec (fluttuante ma circa 7 MB / sec in media)!

Sembra exFatche non funzioni molto bene con file molto grandi (diverse centinaia di gigabyte).

Per un'opzione più rapida e rapida per il salvataggio del disco è possibile utilizzare un file di script sh ed eseguire il file con "sh nomefile.sh". Contiene questa riga mostrata, basta ripetere "sudo ddrescue" e "sleep 3" alcune volte in più, il sonno viene utilizzato per far riposare l'unità alcuni secondi, può essere buono per alcuni motivi:

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

-R0 non ha risposte. Il -e +0 è per errore all'uscita 1. -T 1s si chiude con 1 secondo di errore nella lettura. Ci sono opzioni che possono essere usate come -d per direct e -n per nessuna raschiatura che può accelerare.

Puoi usare -R dopo aver terminato con l'opzione -A una volta, che invertirà e rimuoverà tutti gli errori e ricomincerà indietro. Significa che leggerà gli errori in modo diverso.

dd_rhelp è uno script di shell che utilizza dd_rescue "[...] su tutto il tuo disco, MA proverà a raccogliere i dati massimi validi prima di provare per anni su gruppi di badsector"

è piuttosto vecchio (2012) ma funziona ancora. non ho ancora provato ddrescue.