Utilizzo di ddrescue per recuperare un'unità bloccata. Posso controllare il progresso prima che l'esecuzione sia completa?

Attualmente sto eseguendo ddrescue su un'unità che non mi è ddrescue . E 'in esecuzione per forse 16 ore ora ed è ancora nella fase di divisione bloccato blocchi, ma è stato in esecuzione a 0 B / s per qualche ora. Sto copiando direttamente su un'altra unità, non facendo un'image.

Posso controllare per vedere quali progressi sono stati compiuti o che avverrà qualcosa? C'è solo un progetto sull'unità fallita che ho veramente bisogno, voglio solo controllare se questi file sono stati copiati ancora.

Il command che ho eseguito era:

 ddrescue -d -f -v /dev/sda5 /dev/sdc2 /media/username/USB/rescue.logfile 

Sto eseguendo su Ubuntu, e le vecchie unità OS sono state Arch se questo ha importnza.

One Solution collect form web for “Utilizzo di ddrescue per recuperare un'unità bloccata. Posso controllare il progresso prima che l'esecuzione sia completa?”

In teoria è ansible terminare ( ctrl + C ) ddrescue e eseguirlo successivamente con lo stesso file di log per farlo continuare piuttosto che riprendere. Ho visto alcuni post che affermano che questo metodo non sempre funziona – in questi casi il ddrescue ignorava l'ex lavoro e cominciò fin dall'inizio per la ragione sconosciuta.

Provare a montare la partizione di destinazione in sola lettura:

 sudo mount -o ro /dev/sdc2 /mnt/foo 

Come sola lettura, non dovrebbe ddrescue operazione di ddrescue . Esiste il rischio che i dati cruciali per il filesystem non siano ancora recuperati, in questo caso il mount non riesce. Con una certa fortuna potresti essere in grado di montare, quindi leggere i file necessari, tuttavia i file potrebbero essere danneggiati anche se non si ottiene alcun errore da mount e (ad esempio) cp . Ispezionali o copie. Non terminare ddrescue less che non si assicuri che i file siano validi e che non vi siano frammenti non ripristinati / messi all'interno.

In caso di problemi è ansible attendere il ddrescue per recuperare altri dati (se esistono). Non vorrei aspettare che i file non corrotti appaiano sotto il mountpoint, perché il sistema può memorizzare in cache i metadati oi file stessi, ecc. umount , aspettare di recuperare più dati, mount nuovamente e controllare i file.


Modifica: rispondere a ulteriori domande.

C'è un modo per dire a ddrescue per specificare una particolare cartella?

No. Lo strumento funziona a livello di block. Non sa niente di file system e di file. La tua dichiarazione "ddrescuelog dice che 99,73% dei miei file sono stati recuperati" dovrebbe dire "99,73% dei blocchi".

Inoltre, è ansible che i dati siano stati recuperati, dato che dice che il 99,73% è stato salvato, ma è troppo danneggiato per essere riconosciuto come file? Se questo è il caso c'è qualche programma per visualizzare file danneggiati, forse posso recuperare alcuni di essi manualmente.

Possibile scenario: il contenuto del file viene recuperato ma la corrispondente voce del filesystem non è (nota: generalmente è anche ansible il contrario, ma ovviamente non è il tuo caso). Hai detto che tutta la cartella è andata. Penso che alcuni dei file possono apparire in lost+found dopo fsck (o in modo simile a seconda del tuo filesystem – non so cosa sia).

Ulteriori informazioni qui: Qual è lo scopo della cartella lost + found in Linux e Unix?

Questa operazione fsck non è sola lettura, non dovrebbe essere eseguita quando il ddrescue è in function. Terminare il ddrescue , eseguire fsck e riprendere ddrescue è anche una cosa negativa da fare. È meglio aspettare che il ddrescue finisca. Può richiedere un po 'di tempo – leggere questo e questo .

In generale si dovrebbe lavorare con fsck (o qualsiasi altro strumento non readonly) su una copia dei dati recuperati. Buon modo per andare, per futuri riferimenti:

  1. Scrivi a un file, non un dispositivo. Utilizzare un file system con funzionalità di copia-scrittura (COW) .
  2. Crea una copia COW con cp --reflink=always . È ansible eseguire questa operazione durante il funzionamento di ddrescue . Questa copia è come un'istantanea del file di destinazione.
  3. Utilizzare qualsiasi strumento sulla copia, inclusi quelli non in lettura.
  4. In caso di guasto si ha ancora il file di destinazione originale (forse con più dati recuperati, se il ddrescue è ancora in esecuzione) per iniziare con un'altra copia COW (e forse con diversi strumenti).

Puoi anche provare a cercare i file eliminati e deselezionarli. La scelta di uno strumento dipende dal filesystem.

Un altro suggerimento: forse il tuo software stava utilizzando file temporanei da qualche altra parte nella gerarchia dei filesystem. Controllare /tmp/ , /var/tmp/ .


Modifica, rispondendo a ulteriori domande.

Quando ddrescuelog dice che il 99,73% dei blocchi sono stati salvati cosa significa esattamente? Sembra che dovrei aspettarmi alcuni risultati non un drive vuoto casa.

Nota: un esempio riportto di seguito non è destinato a coprire tutti i problemi di file system e gli scenari, né per distinguere i settori di disco dalle unità di allocazione dei filesystem; è quello di rispondere solo alla domanda.

Immagina che la tua partizione sia un libro – un'enciclopedia, non un romanzo con una plot. I file sono articoli dentro. Il block di disco (o settore) è come una pagina del libro. Il file system è un modo generale per mettere articoli su pagine. Alcune pagine contengono la Table of Contents (ToC) che è una questione di filesystem nella nostra image e può sembrare qualcosa di simile:

articolo # 289: pagine 2076, 2077, 2078, 402, 403.

Si noti che questo articolo è frammentato come un file può essere. Su un'altra pagina, ma ancora all'interno di ToC, abbiamo qualcosa come la struttura delle cartelle:


people/ : vedere ToC a pagina 43.

(pagina 43)
mathematicians/ : vedere ToC a pagina 80.
famous Poles/ : vedere ToC a pagina 82.
Adam and Eve : vedi articolo # 14.

(pagina 80)
Euclid : vedi articolo # 289.
Banach Stefan : vedi articolo # 4380.

(pagina 82)
Banach Stefan : vedi articolo # 4380.
Kościuszko Tadeusz : vedi articolo # 2208.

Questa struttura è un esempio di file collegati. Ci sono alless due routes che puntano a un singolo articolo: ./people/mathematicians/Banach Stefan e ./people/famous Poles/Banach Stefan . Qui ho messo il punto all'inizio di each path, perché il mio esempio nasconde intenzionalmente le informazioni: quale sezione appartengono people/ sezione? (può anche essere /people/ o /full articles/people/ o /stubs/people/ o /foo/bar/people/ ).

Il ToC può anche avere una sezione che dice:

pagine "vuote": 567, 568, 569, 2070, 2071 …

Una data pagina ha text su di esso (cioè i dati) anche se non appartiene ad alcun articolo esistente alla volta. Ciò è dovuto al fatto che un process di eliminazione di un articolo riguarda solo la tabella dei contenuti . Il ToC è l'unico modo certo di sapere se una determinata pagina appartiene ad un articolo, quale articolo, o può essere trattato come vuoto e sovrascritto. Inoltre: non c'è modo di individuare la "pagina vuota" senza ToC . Sembra strano dell'enciclopedia per avere una pagina vuota come parte di un articolo, ma il settore pieno di 0 s o spazi o qualsiasi altra cosa può essere parte di un file. Tutto su ToC .

Alcune delle tue pagine (blocchi) non sono ancora state salvate (ancora). Qualsiasi di esse può essere una pagina con dati di articolo o Toc- metadata. possibilità:

  • Il block mancante è il block dati (ad esempio, pagina 2078). Sai il path dell'articolo su Euclid e su quali pagine è, ma una delle pagine è vuota, mentre non dovrebbe. L'articolo non è valido.
  • Blocco mancante è block metadati. Alcuni scenari:
    • Hai perduto traccia dello spazio libero.
    • Sai che c'è ./people/mathematicians/Euclid path ma ti mancano le informazioni su quali pagine l'articolo è. È imansible trovare l'articolo a less che tu non ne sappia già qualcosa (ad esempio una voce su una persona probabilmente ha una parola "nata"; i file PDF iniziano con "% PDF").
    • Sai che c'è un singolo articolo su tali e simili pagine, ma non esiste un path completo. In questo caso puoi posizionarlo sotto lost+found e questo è quello che fsck farà. Nella nostra image ci sono possibilità (tra le altre):
      • Manca la pagina 80: sai (a partire da pagina 43) c'è sezione (cartella) di mathematicians , ma non sai che l'articolo # 289 dovrebbe essere sotto il nome di "Euclid".
      • Manca la pagina 43: non sapete che dovrebbero essere l'articolo 14 su Adam e Eva, né sezioni con matematici né famosi polacchi; ma si può vedere (a pagina 80) che c'è una sezione con articoli su Euclid e Banach e c'è qualche altra sezione (pagina 82) con articoli su Banach e Kościuszko. Questo è ciò che può accadere con la tua /home . Gli articoli (file) sono presenti e possono essere validi. Non possono essere raggiunti dal path perché non hai Toc della tua /home .
  • Qualsiasi combinazione dei problemi di cui sopra può verificarsi se ci sono più blocchi non recuperati.
  • (EDIT) Il block mancante può essere contrassegnato come vuoto. In questo caso non perdi nulla.
Siamo il genio del computer e della rete.