Questo comando ddrescue sta facendo qualcosa?


9

Nel corso del tentativo di recuperare i dati da un disco rigido guasto , sto eseguendo il comando ddrescue.

Il comando è in esecuzione da 9 giorni e dal suono dell'attività del disco ho pensato che forse stava facendo qualcosa. L'output della riga di comando è apparso più o meno statico per tutto questo tempo:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

L'unica parte che sta cambiando è dove dice ipose opos. Ci sono voluti 9 giorni per arrivare a circa 500000 MB, che è la dimensione dell'unità disco guasta. Quando è arrivato lì, però, è tornato indietro 0e ha ricominciato a salire. Mentre scrivo, è circa 2580 MBe conta.

Il file di immagine che viene creato è lungo 0 byte.

Il file di registro ha una dimensione di circa 3 MB ed è simile al seguente:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Sto iniziando a preoccuparmi del fatto che questa è solo una perdita di tempo e che nessun dato viene recuperato.

C'è qualche indicazione da questo output che sta accadendo qualcosa di utile?

C'è qualche motivo per lasciare che il ddrescuecomando continui così com'è, o dovrei fermarlo e fare qualcos'altro?


Questo è il contenuto più recente di /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

Risposte:


8

Non so se stai ancora cercando di estrarre i dati da quel disco rigido o se hai già avuto successo, ma nel caso in cui non avessi successo e vorresti provarlo per vedere se riesci a recuperare, forse, perso Bitcoin o altro, ho apportato alcune modifiche ai ddrescueparametri della tua riga di comando, ho aggiunto quanto segue:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • -d che dice a ddrescue di usare l'accesso diretto al disco,
  • --force che dice a ddrescue di usare e leggere / scrivere nel file di log in modo forzato nel caso in cui si lamenta di non poterlo utilizzare per scopi di lettura / scrittura
  • -R (sì, con CAPITAL R) che indica ddrescuedi eseguire le operazioni di ripristino al contrario invece di leggere il disco rigido guasto in modalità avanti. A volte la lettura al contrario aiuta quando il danno è sostanziale in quanto ciò ignora la cache del disco rigido nel caso in cui ci siano problemi lì.

Attualmente sto usando questi comandi (tranne che non sto usando il 3comando perché non voglio [ANCORA] ddrescueper riprovare settori danneggiati, lo lascerò per ultimo, dopo che è stata eseguita la mia prima scansione, e sto riscuotendo un grande successo nel salvataggio dati dal mio disco fisso Seagate da 1 TB in cui non potrei avere alcuni bitcoin che potrei aver recuperato nel 2009-2010, probabilmente ho trovato da 1 a 3 blocchi di 50 BTC ciascuno, spero sia su questo disco rigido, beh, mi serviranno un totale di oltre 15 giorni per completare l'operazione con una velocità di lettura media di 634 kbps.

Inoltre, vorrei aggiungere che potresti e molto probabilmente, in base al tuo precedente track record di oltre 9 GIORNI di "ultima attività di lettura" che incontrerai una situazione in cui il disco rigido si rifiuterà di leggere ulteriormente, in quanto situazione, basta premere CTRL + C per annullare poiché si utilizza un file di registro, rimuovere il cavo SATA dal disco rigido guasto, ma non il controller USB dalla porta USB (sì, utilizzare un controller SATA USB invece di collegarlo a una scheda madre in modo da non bloccare l'intero computer forzandoti a riavviare il disco rigido, quindi ricollegare l'alimentazione SATA per riavviare il disco rigido, concederlo come 10 secondi e quindi premere la freccia su o giù per ricaricare il terminale precedente comando e riavvia ilddrescueoperazione, grazie al tuo registro precedente continuerà da dove era stata interrotta l'ultima volta e ci sarà la lettura in corso e l '"ultima lettura riuscita" rimarrà sempre a "0" (zero secondi) dove dovrebbe, indicando che ddrescuesta avendo successo in lettura dal disco rigido e se si nota che "l'ultima lettura da" inizia a contare i secondi, basta terminare di nuovo ddrescuecon CTRL+ C, spegnere e riaccendere il disco rigido e riavviareddrescue, non ha senso aspettare di vedere se l '"ultima lettura da" ricomincia da zero da sola, in base alla mia esperienza non accadrà mai, aspetterai l'eternità. Ho dovuto spegnere e riaccendere il mio cattivo disco rigido da 1 TB circa 20 volte in totale, sono passati circa 7 giorni e sono molto vicino al raggiungimento del segno recuperato da 500 GB, a metà strada per fermarmi, spero di non incontrare grossi guasti poiché Ho quasi raggiunto il 100%, poiché è andata in modo impeccabile negli ultimi 3 giorni, di nuovo a oltre 634 kbps.

Inoltre, non diventare avido nel tentativo di ottenere una velocità di lettura del throughput dei dati più veloce, poiché il mio tentativo di provare molti parametri e blocchi di dimensioni diverse mi ha quasi lasciato un rive completamente morto che smetterà di funzionare in oltre 1 secondo dopo averlo spento e riacceso. (era 5 giorni fa) ma per fortuna è ricominciato a mostrare segni di vita, leggendo inizialmente a 2.000 bs (sì BYTES al secondo) un po 'meno di 2kbps, sono rimasto molto deluso, ma dopo aver annullatoddrescuecon CTRL + C e appena riavviato di nuovo (al contrario con il -R) è stato aggiunto il parametro, quindi la velocità è tornata a 630, prima di leggere in avanti a 930 kbps, almeno sono contento di fare 630 kbps al contrario e non dover rimandare a 2kbps, quindi se hai successo a qualsiasi velocità di lettura, come nella gamma da 500 kbps mantienila e non provi nulla a spingere velocità più alte, potrebbe essere il tuo ultimo tentativo riuscito di guadagnare qualsiasi velocità di lettura.

In alternativa, se ddrescuenon ti va bene perché non riesci a leggere nulla indipendentemente dai parametri che provi, potresti prendere in considerazione la sostituzione della scheda logica dal disco rigido, poiché il 90% delle volte è la scheda logica che va male, ma prima, togli la scheda logica e pulisci tutti i contatti che stabiliscono i contatti con i pin del disco rigido, a volte questi contatti ottengono una miscela appiccicosa nerastra, recidendo i contatti che potrebbero essere la fonte del tuo fallimento. Ma tieni presente che se devi sostituire la scheda logica del tuo disco rigido, dovrai ottenere uno stesso marchio, numero di serie (vicino a), numero di modello, numero di revisione perché deve essere vicino all'originale per la commissione dei donatori al lavoro.


2
Potresti voler modificare un po 'quel muro di testo.
slm

4
In realtà, ho pensato che fosse uno dei post più costruttivi e dettagliati che ho visto sull'argomento. Spero non ti dispiaccia, ho appena aggiunto una domanda simile unix.stackexchange.com/q/219365/125662 che menziona il tuo contributo davvero utile
baroquedub

1
Dal manuale GNU ddrescue: "--force Force overwrite of outfile. Necessario quando outfile non è un file normale, ma un dispositivo o una partizione. Questa opzione è solo una salvaguardia per prevenire la distruzione involontaria di partizioni e viene ignorata per i file regolari ". Non si tratta di mapfile / logfile.
Arch Linux Tux,

Correggi la descrizione --forcedell'opzione, non è corretta
endolith il

5

Dovresti essere in grado di interrompere ddrescuepoiché utilizza il file di registro per poter riavviare l'operazione (vicino) da dove era rimasto. Vorrei comunque verificare se il file di registro è stato aggiornato di recente osservando il timestamp o facendo tail -f /home/dave/recovery_usb500.logfile.

Che il tuo file di immagine sia ancora così piccolo potrebbe non avere a che fare con blocchi che non sono stati ancora recuperati dall'unità. Sarebbe comunque un brutto risultato dopo tutto questo tempo di esecuzione. Supponendo che ci siano solo alcuni blocchi danneggiati sul dispositivo e che non siano all'inizio, lo stato delle prime voci sarebbe +. IIRC ddrescueinizia a leggere fino a quando non rileva un errore, quindi inizia a dividere il resto del disco. Il tuo disco sembra non funzionare fin dall'inizio.

A meno che non ci siano (più) +voci nel registro e le dimensioni del tuo file sarebbero comunque 0non credo ddrescuesia sbagliato. Non +significa che non è stato possibile recuperare nulla dal disco rigido. Ciò potrebbe significare elettronica fritta o una brutta testa, poiché nel caso in cui solo pochi settori fossero difettosi, i risultati sarebbero stati molto più rapidi.

Quanto a fare qualcos'altro. Presumo che tu abbia già provato a leggere alcuni blocchi con normale dd. Hai guardato il syslog in base a quello e hai cercato su Google qualche messaggio che hai trovato lì?


La ricerca di "Risultato: hostbyte = driverbyte non valido = DRIVER_SENSE" genera alcune letture interessanti (in parte tedesche) con alcuni altri suggerimenti:

  • Prova a connetterti tramite USB 1.1 anziché 2.0
  • L'unità potrebbe surriscaldarsi, quindi avvolgerla in plastica e metterla in frigorifero per 10 minuti, questo dà un po 'di tempo di leggibilità prima che l'unità si riscaldi di nuovo.
  • switch di SMART nel BIOS (e connettersi con SATA).
  • Assicurarsi che l'unità USB abbia abbastanza potenza (alimentatore extra)
  • Se la lettura tramite USB non riesce dopo un po 'di tempo, utilizzare un hub USB controllato a distanza in cui è possibile passare a livello di programmazione dall'hub USB all'unità per alcuni secondi.

A parte il raffreddamento di un disco illeggibile (con spray di raffreddamento) non ho provato nessuno di questi.


Grazie per aver risposto. Non ho provato un "normale" dd, in quanto non so cosa sia. La mia sensazione è che la maggior parte dell'unità e dei dati siano intatti, ma c'è qualche errore in alcune aree critiche del disco in cui si verificano i file di indicizzazione o elenco.
Interrogante

Si potrebbe considerare ddrescueuna derivata ddche non si interrompe quando si verifica un errore. Hai controllato +segni?
Anthon,

Nel file di registro, non ci sono +segni. Ci sono solo -e \ segni.
Interrogante

Ciò significa che non è stato ancora recuperato nulla e penso che sia improbabile che ddrescueinizi dopo tutto questo tempo. Se vuoi, possiamo chattare (link all'inizio di questa pagina) a riguardo
Anthon,

Ho aggiunto il contenuto della /var/log/syslogdomanda.
Interrogante
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.