Salvataggio di un hdd con settori danneggiati: dd vs gddrescue

Da qualche parte su Internet ho letto che gddrescue è superiore a dd almeno in termini di essere in grado di distinguere tra la quantità di letture del disco eseguite su un settore problematico. È davvero così?

tempo dd if = / dev / sda skip = 900343967 di = a.bin count = 4 iflag = direct conv = noerror, sync

dd: lettura `/ dev / sda ': errore di input / output
2 + 0 registra in
2 + 0 registra fuori
1024 byte (1,0 kB) copiato, 18.6057 s, 0.1 kB / s
3 + 1 registra in
4 + 0 registra fuori
2048 byte (2,0 kB) copiati, 18,6707 s, 0,1 kB / s

reale 0m18.672s
utente 0m0.000s
sys 0m0.004s

A proposito, la bandiera diretta aiuta davvero, senza di essa sono stato in grado di leggere solo 1 settore su 4 (vs 3/4 con esso). Tuttavia, ciò rallenta notevolmente la velocità di trasferimento - è almeno circa 5 volte più lento per me: 5 MB / s contro 25 MB / s senza questo flag. Comunque, ora per la parte gddrescue (ddrescue) ..

time ddrescue -b512 -c1 -s4b -dnvD -i900343967b -o0b / dev / sda b.bin

Per copiare 2048 byte da / dev / sda a b.bin
Posizioni iniziali: infile = 460976 MB, file in uscita = 0 B
Dimensione blocco copia: 1 blocchi
rigidi Dimensione blocco rigido: 512 byte
Max_retries: 0
Diretto: sì Rado : no Split: no Tronca: no

Premi Ctrl-C per interrompere il
salvataggio: 1536 B, errsize: 512 B, velocità corrente: 53 B / s
ipos: 460976 MB, errori: 1, frequenza media: 53 B / s
opos: 1536 B, tempo dall'ultima lettura riuscita: 0 s
Terminato

reale 0m18.736s
utente 0m0.004s
sys 0m0.000s

Come mostrato sopra, ci è voluto esattamente lo stesso tempo per l'esecuzione. Come previsto - stesse statistiche: 3/4. Tuttavia, mentre potrei riempire i settori problematici con 0x00 per dd (conv = sync), sembra che a gddrescue manchi questa funzionalità? Invece, salta semplicemente il settore problematico senza scrivere nulla nella sua posizione e continua con il seguente settore successivo (se ho già i dati scritti su quel settore nel file di output - non verrà sovrascritto: a volte ciò potrebbe non essere desiderabile ). Non sono sicuro di come funzionerà l' opzione -t (troncare) per un dispositivo a blocchi con gddrescue(immagino, lo sovrascriverà completamente con 0x00), ma su un file normale, come previsto, troncerà l'intero file senza farlo entro le dimensioni di offset (cioè -o1). Quindi, è in qualche modo simile a dd sync , ma lungi dall'essere lo stesso poiché imiterà la funzionalità identica solo se si è pronti a sovrascrivere l'intero dispositivo / file di output.

Sebbene, grazie alla presenza dell'opzione dettagliata e alla possibilità di registrare settori / blocchi danneggiati , gddrescue sembra una scelta migliore. È importante notare che entrambe le app sono state lanciate con parametri (praticamente) identici.

L'output di

diff? .bin

è vuoto (uscita 0), il che significa che i file sono esattamente gli stessi.

Ora questa è la parte che NON capisco:

dd è lento anche su cose prive di errori dato che sta facendo letture e scritture minuscole. Trascorre molto tempo a masticare attraverso le parti errate del disco, piuttosto che leggere quante più cose possibile prive di errori, quindi tornare a fare le cose difficili.

Di cosa si tratta? Soprattutto la parte " passa molto tempo a masticare attraverso le parti errate del disco, piuttosto che leggere quante più cose prive di errori possibile, POI tornare a fare le cose difficili "? Ci è voluto lo stesso tempo mostrato sopra (anche se ho ispezionato una porzione molto piccola di dati, ma dovrebbe importare?).

gddrescue offre l' opzione -r , che dovrebbe controllare la quantità di riletture su un "settore danneggiato", tuttavia dd sembra funzionare insieme a -r0 (dato che ci è voluto nello stesso tempo). Quindi, questa opzione è solo per "post-elaborazione"? Quello a cui sto arrivando è che in origine sia dd che gddrescue sembrano funzionare con -r0 e dd non sembrano masticarsi attraverso le parti errate non più di gddrescue (entrambi sembrano fermarsi su un brutto blocco per 15-18 secondi dai o dai, quindi qual è il problema, come è gddrescue più veloce ???)

Inoltre, a cosa serve l' opzione -D (usa le scritture sincrone per il file di output)? Non ho notato alcuna differenza rispetto ad alcuni dei test condotti.

Qualcuno può commentare l'intera faccenda? Grazie.

Non sono sicuro di come l'autore citato sia giunto alla sua conclusione. Non sto discutendo se ha ragione o no, semplicemente non ho quell'esperienza.

D'altra parte, riguardo a questa affermazione ...

gddrescue è superiore a dd almeno in termini di essere in grado di distinguere tra la quantità di letture del disco eseguite su un settore problematico.

Il vero "almeno" motivo per usare gddrescue è perché gddrescue non tronca l'output in ripetuti tentativi di lettura / scrittura. gddrescue è anche completamente automatico, per quanto riguarda alcuni errori di lettura che interrompono dd.

Quindi l'autore citato potrebbe essere corretto, potrebbe non ... ma l'intera affermazione manca il punto di gddrescue.

AGGIORNAMENTO: Differenze dettagliate tra dd e gddrescue.

dd conv = noerror, continuerà dopo un errore, ma salterà semplicemente il blocco danneggiato. anche l'aggiunta dell'opzione di sincronizzazione metterà solo zeri invece di saltare. Se usi dd per fare un'altra lettura usando lo stesso output, sovrascrivi / perdi tutto ciò che hai recuperato in precedenza.

gddrescue, continuerà anche dopo l'errore. Può recuperare un rendimento parziale da un blocco difettoso e tornerà indietro e tenterà il blocco settore per settore. gddrescue manterrà un registro degli errori dettagliato, con blocchi buoni, blocchi danneggiati e settore per settore da eventuali blocchi danneggiati. Se si tenta di eseguire nuovamente la lettura, gddrescue interromperà (troncerà) e aggiungerà tutti i dati recuperati ulteriormente.

Ricordati, anche con entrambi gli strumenti, se un intero blocco è illeggibile al 100%. Non otterrai ancora dati da esso. gddrescue può potenzialmente ottenere più dati, se alcuni settori nel blocco rimangono leggibili.

A seconda del momento in cui il tuo hdd è stato prodotto e del produttore, e quale versione del firmware viene eseguita, con i moderni hdd, quando vengono rilevati settori danneggiati, vengono rimossi dall'uso dal firmware e l'unità sa di saltare i settori danneggiati. Quindi, l'idea di "salvare" un hdd da settori danneggiati potrebbe essere controversa in questo senso. La domanda se i settori ormai in rovina una volta disponessero di dati validi sembra essere la soluzione del caso che stai cercando - nessun gioco di parole previsto!

Esiste un software su grc.com chiamato spinrite 6 che afferma di essere in grado di riparare HDD con settori danneggiati. È un software a pagamento e non l'ho mai provato. Vale la pena leggere, specialmente se si sta tentando di "resuscitare" un hdd e funziona davvero come descritto. Le FAQ su grc.com relative a spinrite 6 indicano che esiste una garanzia di rimborso di 30 giorni (e non esiste una versione di prova o gratuita). Nota: non sono affiliato a grc.com, né lo sto raccomandando per la tua situazione. So solo che esiste e potrebbe funzionare come pubblicizzato, semplicemente non credermi sulla parola: avvertimento.

Per quanto riguarda la valutazione se gddrescue "è superiore" a dd almeno in termini di capacità di distinguere tra la quantità di letture del disco eseguite su un settore problematico, un numero qualsiasi di letture su un settore danneggiato (poiché è contrassegnato come non settore funzionale in un elenco di settori danneggiati tenuti in un elenco di firmware) non mi sembrerebbe utile in un uso qualitativo di gddrescue o dd.

Potresti trovare utile leggere la pagina web, dd (Unix) su: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd

Potresti anche trovare utile dare un'occhiata a: Come creare un'immagine di un disco rigido danneggiato utilizzando UBCD, dd-rescue e P2 eXplorer su: http://www.myfixlog.com/fix.php?fid= 21