¿Cómo estimar bucles / tiempo para completar GNU ddrescue (1.18.1) usando el estado actual?

Antecedentes / contexto:

Actualmente estoy ejecutando GNU ddrescue 1.18.1 para recuperar datos de un USB que experimentó una desconexión del cable mientras escribía una imagen de disco virtual en la partición disk2s1. Inicialmente estoy recuperando mi segunda partición (disk2s2) y noto que he alcanzado la tercera fase (división). Estoy colocando la imagen en un almacenamiento de red.

Pregunta:

He notado que esta fase se repite. ¿Hay alguna manera de calcular la cantidad de bucles que probablemente experimentaré, dada mi información de estado actual (solo estoy mostrando dos errores)?

Estado:

Actualizar / Editar:

Así que todavía estoy muy interesado en cómo uno podría estimar los ciclos / tiempo para completar usando la herramienta ddrescue. Según los comentarios, estoy agregando una evaluación de un archivo de registro para mi partición disk2s1 que se está ejecutando actualmente (el disk2s2 se ha completado después de 14.5 horas, con una interrupción del usuario durante aproximadamente 6 horas).

Registro de partición completado

Para la partición que acaba de completar, aquí está el resultado de la inspección del registro.

Referencia (notas del algoritmo ddrescue):

4 algoritmo

GNU ddrescue no es un derivado de dd, ni está relacionado con dd de ninguna manera, excepto en que ambos pueden usarse para copiar datos de un dispositivo a otro. La diferencia clave es que ddrescue utiliza un algoritmo sofisticado para copiar datos de unidades defectuosas, causándoles el menor daño adicional posible.

Ddrescue gestiona eficientemente el estado del rescate en progreso e intenta rescatar las partes buenas primero, programando las lecturas dentro de las áreas malas (o lentas) para más adelante. Esto maximiza la cantidad de datos que finalmente se pueden recuperar de una unidad que falla.

La utilidad dd estándar se puede usar para guardar datos de una unidad que falla, pero lee los datos secuencialmente, lo que puede desgastar la unidad sin rescatar nada si los errores están al comienzo de la unidad.

Otros programas leen los datos secuencialmente pero cambian a lecturas de tamaño pequeño cuando encuentran errores. Esta es una mala idea porque significa pasar más tiempo en áreas de error, dañando la superficie, los cabezales y la mecánica de la transmisión, en lugar de salir de ellos lo más rápido posible. Este comportamiento reduce las posibilidades de rescatar los datos buenos restantes.

El algoritmo de ddrescue es el siguiente (el usuario puede interrumpir el proceso en cualquier momento, pero tenga en cuenta que una unidad defectuosa puede bloquear ddrescue durante mucho tiempo hasta que el núcleo se dé por vencido):

1) Opcionalmente, lea un archivo de registro que describa el estado de un rescate de varias partes o previamente interrumpido. Si no se especifica ningún archivo de registro o está vacío o no existe, marque todo el dominio de rescate como no probado.

2) (Primera fase; Copia) Lea las partes no probadas del archivo de entrada, marque los bloques fallidos como no recortados y salte más allá de ellos. Salta también más allá de las áreas lentas. Las áreas omitidas se prueban más tarde en dos pasadas adicionales (antes de recortar), invirtiendo la dirección después de cada pasada hasta que se pruebe todo el dominio de rescate. El tercer pase es un pase de barrido, con saltos desactivados. (El propósito es delimitar rápidamente los errores grandes, mantener el archivo de registro pequeño y producir buenos puntos de partida para el recorte). Solo las áreas no probadas se leen en bloques grandes. El recorte, la división y el reintento se realizan sector por sector. Cada sector se prueba como máximo dos veces; el primero en este paso (generalmente como parte de una lectura de bloque grande, pero a veces como lectura de un solo sector), el segundo en uno de los pasos a continuación como lectura de un solo sector.

3) (Segunda fase; Recorte) Lea hacia adelante un sector a la vez desde el borde de ataque del bloque no recortado más pequeño, hasta encontrar un sector defectuoso. Luego, lea hacia atrás un sector a la vez desde el borde posterior del mismo bloque, hasta encontrar un sector defectuoso. Para cada bloque no recortado, marque los sectores defectuosos encontrados como sectores defectuosos y marque el resto de ese bloque como no dividido sin intentar leerlo. Repita hasta que no haya más bloques no recortados. (Los bloques grandes no recortados se producen por concatenación de los más pequeños y, por lo tanto, su fracción de datos buenos en los bordes es más pequeña).

4) (Tercera fase; División) Lea hacia adelante un sector a la vez desde el centro del bloque no dividido más grande, hasta que se encuentre un sector defectuoso. Luego, si el sector defectuoso encontrado no es el primero que se intentó, lea hacia atrás un sector a la vez desde el centro del mismo bloque, hasta que se encuentre un sector defectuoso. Si el archivo de registro es mayor que '--logfile-size', lea secuencialmente los bloques no divididos más grandes hasta que el número de entradas en el archivo de registro caiga por debajo de '--logfile-size'. Repita hasta que todos los bloques no divididos restantes tengan menos de 7 sectores. Luego lea los bloques no divididos restantes secuencialmente.

5) (Cuarta fase; Reintento) Opcionalmente, intente volver a leer los sectores defectuosos hasta alcanzar el número especificado de reintentos. Cada sector defectuoso se prueba solo una vez en cada pasada. Ddrescue no puede saber si un sector defectuoso es irrecuperable o si finalmente se leerá después de algunos reintentos.

6) Opcionalmente, escriba un archivo de registro para su uso posterior.

El tamaño total del error ('errsize') es la suma de los tamaños de todos los bloques no recortados, no divididos y de sectores defectuosos. Aumenta durante la fase de copia y puede disminuir durante el recorte, la división y el reintento. Tenga en cuenta que a medida que ddrescue divide los bloques fallidos, haciéndolos más pequeños, el tamaño total del error puede disminuir mientras aumenta el número de errores.

El archivo de registro se guarda periódicamente en el disco, así como cuando ddrescue finaliza o se interrumpe. Entonces, en caso de un accidente, puede reanudar el rescate con poca copia. El intervalo entre guardar varía de 30 segundos a 5 minutos dependiendo del tamaño del archivo de registro (los archivos de registro más grandes se guardan a intervalos más largos).

Además, el mismo archivo de registro se puede usar para múltiples comandos que copian diferentes áreas del archivo de entrada y para múltiples intentos de recuperación en diferentes subconjuntos. Ver este ejemplo:

Rescata primero la parte más importante del disco. ddrescue -i0 -s50MiB / dev / hdc hdimage logfile ddrescue -i0 -s1MiB -d -r3 / dev / hdc hdimage logfile

Luego rescata algunas áreas clave del disco. ddrescue -i30GiB -s10GiB / dev / hdc hdimage logfile ddrescue -i230GiB -s5GiB / dev / hdc hdimage logfile

Ahora rescata al resto (no vuelve a copiar lo que ya está hecho). ddrescue / dev / hdc archivo de registro de hdimage ddrescue -d -r3 / dev / hdc archivo de registro de hdimage

A pesar de que la pregunta se hizo hace 10 meses, la respuesta podría ser relevante porque el ciclo de recuperación podría estar ejecutándose dependiendo de algunos factores. Sin juego de palabras.

La razón es que la estimación del tiempo es casi imposible, sin embargo, a veces se puede obtener una idea aproximada de la siguiente manera. Una de las razones más obvias es que no puede predecir cuánto tiempo le tomará a la unidad leer un sector defectuoso y si desea que ddrescue lea y vuelva a intentar cada uno, entonces podría llevar mucho tiempo. Por ejemplo, actualmente estoy ejecutando una recuperación en una pequeña unidad de 500 GB que ha estado funcionando durante más de 2 semanas y posiblemente me quedan algunos días. Pero la mía es una situación más complicada porque la unidad está encriptada y para leer cualquier cosa con éxito, me aseguro de obtener todos los sectores que tienen tablas de partición, sectores de arranque y otras partes importantes del disco. Estoy usando técnicas además de ddrescue para mejorar mis posibilidades para todos los sectores defectuosos. IOW

Por estimación de "bucles", si te refieres al número de reintentos, eso es algo que determinas por los parámetros que utilizas. Si quiere decir "número total de pasadas", eso se determina fácilmente al leer sobre el algoritmo aquí .. > man ddrescue </ Algoritmo: Cómo ddrescue recupera los datos

Hablaré específicamente con los números en las capturas de pantalla que proporcionó. Otras situaciones pueden tener otros factores que se aplican, así que tome esta información como una guía general.

En la muestra que ha proporcionado, eche un vistazo a la pantalla de estado de ejecución de ddrescue. Obtenemos la "estimación" total del problema (dominio de rescate) por "errsize". Esta es la cantidad de datos que "aún no se han leído". En la muestra es de 345 GB. La siguiente línea a la derecha es "tasa promedio". En la muestra es 583kb / s

Si la "tasa promedio" se mantuviera cerca de estable, esto significa que le quedan 7 días más. 345 GB / (583 kb * 60 * 60 * 24) = 7.18 Sin embargo, el problema es que no puede confiar en los 583kb / s. De hecho, a medida que avanza en la recuperación, el disco se vuelve más lento ya que lee áreas cada vez más difíciles y está haciendo más reintentos. Entonces, el tiempo para terminar aumenta exponencialmente. Todo esto depende de qué tan dañado esté el disco.

La muestra que proporcionó muestra que una "lectura exitosa" fue hace más de 10 horas. Eso significa que en realidad no obtendrá nada del disco durante más de 10 horas. Esto muestra que su unidad puede tener un valor de 345 GB (o una porción) de disparo de datos. Estas son muy malas noticias para ti.

Por el contrario, mi segundo disco de 500 GB que acababa de comenzar a darme errores "INTELIGENTES", se copió de disco a disco (con el archivo de registro en otro disco) y toda la operación tardó entre 8 y 9 horas. La última parte de esto se ralentizó. Pero eso todavía es soportable. Si bien el disco muy malo, como se señaló anteriormente, ya pasó 2 semanas trabajando con 500 GB y todavía le queda entre un 4 y un 5% para recuperarse.

HTH y YMMV