Come stimare loop / tempo per il completamento di GNU ddrescue (1.18.1) usando lo stato attuale?

Background / Contesto:

Attualmente sto eseguendo GNU ddrescue 1.18.1 per recuperare dati da una USB che ha subito una disconnessione del cavo mentre scrivevo un'immagine disco virtuale sulla partizione disk2s1. Inizialmente sto recuperando la mia seconda partizione (disk2s2) e noto che ho raggiunto la terza fase (suddivisione). Sto posizionando l'immagine su una memoria di rete.

Domanda:

Ho notato che questa fase va in loop. Esiste un modo per calcolare il numero di loop che probabilmente ho riscontrato, date le mie informazioni sullo stato corrente (sto mostrando solo due errori)?

Stato:

Aggiornamento / Modifica:

Quindi sono ancora molto interessato a come si potrebbero stimare i cicli / tempo per il completamento usando lo strumento ddrescue. Secondo i commenti, sto aggiungendo una valutazione di un file di registro per la mia partizione disk2s1 mentre è attualmente in esecuzione (disk2s2 è stato completato dopo 14,5 ore, con un'interruzione di un utente per circa 6 ore).

Registro delle partizioni completato

Per la partizione appena completata, ecco il risultato dell'ispezione del registro.

Riferimento (note dell'algoritmo ddrescue):

4 algoritmo

GNU ddrescue non è un derivato di dd, né è correlato a dd in alcun modo, tranne per il fatto che entrambi possono essere utilizzati per copiare i dati da un dispositivo all'altro. La differenza fondamentale è che ddrescue utilizza un sofisticato algoritmo per copiare i dati da unità guaste causando il minor danno aggiuntivo possibile.

Ddrescue gestisce in modo efficiente lo stato del salvataggio in corso e cerca innanzitutto di salvare le parti buone, programmando le letture all'interno di aree danneggiate (o lente) per dopo. Ciò massimizza la quantità di dati che possono essere finalmente recuperati da un'unità guasta.

L'utilità dd standard può essere utilizzata per salvare i dati da un'unità guasta, ma legge i dati in sequenza, il che può logorare l'unità senza salvare nulla se gli errori sono all'inizio dell'unità.

Altri programmi leggono i dati in sequenza ma passano a letture di piccole dimensioni quando trovano errori. Questa è una cattiva idea perché significa dedicare più tempo alle aree di errore, danneggiare la superficie, le testine e la meccanica della trasmissione, invece di uscirne il più velocemente possibile. Questo comportamento riduce le possibilità di salvare i dati validi rimanenti.

L'algoritmo di ddrescue è il seguente (l'utente può interrompere il processo in qualsiasi momento, ma attenzione che un'unità guasta può bloccare ddrescue per lungo tempo fino a quando il kernel non si arrende):

1) Opzionalmente leggere un file di registro che descrive lo stato di un salvataggio in più parti o precedentemente interrotto. Se non viene specificato alcun file di registro o è vuoto o non esiste, contrassegnare tutto il dominio di ripristino come non provato.

2) (Prima fase; Copia) Leggere le parti non provate del file di input, contrassegnando i blocchi non funzionanti come non tagliati e saltandoli oltre. Salta anche oltre le aree lente. Le aree saltate vengono tentate in seguito in due passaggi aggiuntivi (prima del taglio), invertendo la direzione dopo ogni passaggio fino a quando non viene provato tutto il dominio di salvataggio. Il terzo passaggio è un passaggio ampio, con salto disabilitato. (Lo scopo è di delimitare rapidamente errori di grandi dimensioni, mantenere piccolo il file di registro e produrre buoni punti di partenza per il taglio). Solo le aree non provate vengono lette in blocchi di grandi dimensioni. Il taglio, la divisione e il nuovo tentativo vengono eseguiti settore per settore. Ogni settore viene provato al massimo due volte; il primo in questo passaggio (di solito come parte di un blocco di grandi dimensioni letto, ma a volte come lettura di un singolo settore), il secondo in uno dei passaggi seguenti come lettura di un singolo settore.

3) (Seconda fase; Rifilatura) Leggere in avanti di un settore alla volta dal bordo anteriore del blocco non tagliato più piccolo, fino a quando non viene trovato un settore danneggiato. Quindi leggi indietro un settore alla volta dal bordo di uscita dello stesso blocco, fino a quando non viene trovato un settore danneggiato. Per ogni blocco non tagliato, contrassegnare i settori danneggiati trovati come settori danneggiati e contrassegnare il resto di quel blocco come non suddiviso senza provare a leggerlo. Ripetere fino a quando non ci sono più blocchi non tagliati. (I grandi blocchi non tagliati sono prodotti dalla concatenazione di quelli più piccoli e la sua frazione di buoni dati ai bordi è quindi più piccola).

4) (Terza fase; divisione) Leggere in avanti un settore alla volta dal centro del blocco non diviso più grande, fino a quando non viene trovato un settore danneggiato. Quindi, se il settore danneggiato trovato non è il primo provato, leggi indietro un settore alla volta dal centro dello stesso blocco, fino a quando non viene trovato un settore cattivo. Se il file di log è maggiore di "--logfile-size", leggi in sequenza i blocchi non divisi più grandi fino a quando il numero di voci nel file di log non scende al di sotto di "--logfile-size". Ripetere l'operazione fino a quando tutti i blocchi non divisi rimanenti hanno meno di 7 settori. Quindi leggere i blocchi rimanenti non divisi in sequenza.

5) (Quarta fase; Nuovo tentativo) In alternativa, provare a rileggere i settori danneggiati fino al raggiungimento del numero specificato di tentativi. Ogni settore danneggiato viene provato solo una volta in ogni passaggio. Ddrescue non può sapere se un settore danneggiato è irrecuperabile o se verrà infine letto dopo alcuni tentativi.

6) Opzionalmente scrivere un file di log per un uso successivo.

La dimensione totale dell'errore ('errsize') è la somma delle dimensioni di tutti i blocchi non tagliati, non divisi e di settori danneggiati. Aumenta durante la fase di copia e può diminuire durante il taglio, la divisione e il nuovo tentativo. Si noti che quando ddrescue divide i blocchi non riusciti, rendendoli più piccoli, la dimensione totale dell'errore può diminuire mentre aumenta il numero di errori.

Il file di registro viene periodicamente salvato su disco, così come quando ddrescue termina o viene interrotto. Quindi, in caso di incidente, è possibile riprendere il salvataggio con poco ricopia. L'intervallo tra i salvataggi varia da 30 secondi a 5 minuti a seconda della dimensione del file di registro (i file di registro più grandi vengono salvati a intervalli più lunghi).

Inoltre, lo stesso file di log può essere utilizzato per più comandi che copiano diverse aree del file di input e per più tentativi di recupero su diversi sottoinsiemi. Vedi questo esempio:

Salvare prima la parte più importante del disco. ddrescue -i0 -s50MiB / dev / hdc file di registro hdimage ddrescue -i0 -s1MiB -d -r3 / dev / hdc file di registro hdimage

Quindi salvare alcune aree chiave del disco. ddrescue -i30GiB -s10GiB / dev / hdc file di registro hdimage ddrescue -i230GiB -s5GiB / dev / hdc file di registro hdimage

Ora salva il resto (non ricopia ciò che è già stato fatto). ddrescue / dev / hdc file di registro hdimage ddrescue -d -r3 / dev / hdc file di registro hdimage

Anche se la domanda è stata posta 10 mesi fa, la risposta potrebbe essere pertinente perché il ciclo di recupero potrebbe essere ancora in esecuzione a seconda di alcuni fattori! Nessun gioco di parole previsto.

Il motivo è che la stima del tempo è quasi impossibile, tuttavia a volte potresti avere un'idea approssimativa come segue. Uno dei motivi più ovvi è che non è possibile prevedere quanto tempo impiegherà l'unità a leggere un settore danneggiato e se si desidera che ddrescue legga e riprovi ognuno, potrebbe richiedere molto tempo. Ad esempio, sto attualmente eseguendo un ripristino su un piccolo disco da 500 GB che dura da oltre 2 settimane e probabilmente mi restano ancora alcuni giorni. Ma la mia è una situazione più complicata perché l'unità è crittografata e per leggere qualcosa con successo, ho fatto in modo di ottenere tutti i settori che hanno tabelle di partizione, settori di avvio e altre parti importanti del disco. Sto usando tecniche oltre a ddrescue per migliorare le mie possibilità per tutti i settori danneggiati. IOW,

Per stima dei "loop", se si intende il numero di tentativi, questo è qualcosa che si determina in base ai parametri utilizzati. Se intendi "numero totale di passaggi", questo può essere facilmente determinato leggendo l'algoritmo qui. > Man ddrescue </ Algorithm: come ddrescue recupera i dati

Parlerò in particolare con i numeri nelle schermate che hai fornito. Altre situazioni possono avere altri fattori applicabili, quindi prendi queste informazioni come linee guida generali.

Nell'esempio che hai fornito dai un'occhiata alla schermata dello stato di esecuzione di ddrescue. Otteniamo la "stima" totale del problema (dominio di salvataggio) con "errsize". Questa è la quantità di dati che "devono ancora essere letti". Nel campione è 345 GB. La riga successiva in basso a destra è "tariffa media". Nel campione è 583kb / s

Se il "tasso medio" dovesse rimanere vicino al costante, ciò significa che hai ancora 7 giorni. 345 GB / (583 kb * 60 * 60 * 24) = 7.18 Tuttavia il problema è che non puoi fare affidamento su 583kb / s. In effetti, più in profondità si avvia il ripristino, l'unità diventa più lenta poiché sta leggendo aree sempre più difficili e sta facendo più tentativi. Quindi il tempo per terminare esponenzialmente aumenta. Tutto ciò dipende da quanto gravemente l'unità è danneggiata.

L'esempio che hai fornito mostra che una "lettura riuscita" è stata eseguita oltre 10 ore fa. Ciò significa che non sta ottenendo nulla dall'unità per oltre 10 ore. Ciò dimostra che l'unità potrebbe avere un valore di 345 GB (o una porzione) di dati sparati. Questa è una brutta notizia per te.

Al contrario, la mia seconda unità da 500 GB che aveva appena iniziato a darmi errori "SMART", è stata copiata da disco a disco (con il file di registro su un'altra unità) e l'intera operazione è durata circa 8-9 ore. L'ultima parte ha rallentato. Ma è ancora sopportabile. Mentre la pessima unità, come notato sopra, è ben passata 2 settimane a lavorare su 500 GB e ha ancora circa il 4-5% rimanente da recuperare.

HTH e YMMV