Rescatando un disco duro con sectores defectuosos: dd vs gddrescue


11

En algún lugar de Internet , leí que gddrescue es superior a dd al menos en términos de poder distinguir entre la cantidad de lecturas de disco realizadas en un sector con problemas. ¿Es este realmente el caso?

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

dd: lectura `/ dev / sda ': error de entrada / salida
2 + 0 registros en
2 + 0 registros de
1024 bytes (1.0 kB) copiados, 18.6057 s, 0.1 kB / s
3 + 1 registros en
4 + 0 registros
2048 bytes (2.0 kB) copiados, 18.6707 s, 0.1 kB / s


usuario real 0m18.672s 0m0.000s
sys 0m0.004s

Por cierto, la bandera directa realmente ayuda, sin eso solo pude leer 1 sector de 4 (vs 3/4 con él). Sin embargo, eso reduce notablemente la velocidad de transferencia: es al menos aproximadamente 5 veces más lento para mí: 5 MB / s frente a 25 MB / s sin este indicador. De todos modos, ahora para el gddrescue parte (ddrescue) ..

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

A punto de copiar 2048 Bytes de / dev / sda a b.bin
Posiciones iniciales: archivo = 460976 MB, archivo externo = 0 B
Copiar tamaño de bloque: 1 bloques
duros Tamaño de bloque duro: 512 bytes
Max_retries: 0
Directo: sí Escaso: no Split: no Truncar: no

Presione Ctrl-C para interrumpir el
rescate: 1536 B, error: 512 B, tasa actual: 53 B / s
ipos: 460976 MB, errores: 1, tasa promedio: 53 B / s
opos: 1536 B, tiempo desde la última lectura exitosa: 0 s
terminado


usuario real 0m18.736s 0m0.004s
sys 0m0.000s

Como se muestra arriba, ha llevado exactamente la misma cantidad de tiempo para la ejecución. Como se esperaba, mismas estadísticas: 3/4. Sin embargo, si bien podría rellenar los sectores problemáticos con 0x00 para dd (conv = sync), ¿ parece que gddrescue no tiene esta funcionalidad? En cambio, simplemente omite el sector problemático sin escribir nada en su posición y continúa con el siguiente sector siguiente (si ya tengo datos escritos sobre ese sector en el archivo de salida, no se sobrescribirá: a veces eso podría no ser deseable ) No estoy seguro de cómo funcionará la opción -t (truncar) para un dispositivo de bloque con gddrescue(supongo que lo sobrescribirá por completo con 0x00), pero en un archivo normal, como se predijo, truncará todo el archivo sin hacerlo solo dentro de las dimensiones de desplazamiento (es decir, -o1). Por lo tanto, eso es algo similar a la sincronización de dd , pero lejos de ser lo mismo, ya que solo imitará la funcionalidad de identificación SI está listo para sobrescribir todo el dispositivo / archivo de salida.

Aunque, gracias a la presencia de la opción detallada y la capacidad de registrar sectores / bloques defectuosos , gddrescue parece una mejor opción. Es importante tener en cuenta que ambas aplicaciones se lanzaron con (casi) parámetros idénticos.

La salida de

diff? .bin

está vacío (salida 0), lo que significa que los archivos son exactamente iguales.

Ahora esta es la parte que NO entiendo:

dd es lento incluso en el material libre de errores, ya que está haciendo pequeñas lecturas y escrituras. Pasa mucho tiempo masticando las partes erróneas del disco, en lugar de leer tantas cosas libres de errores como pueda, y luego volver a hacer las cosas difíciles.

¿Qué es todo eso? ¿Especialmente la parte " pasa mucho tiempo masticando las partes erróneas del disco, en lugar de leer tantas cosas libres de errores como pueda, ENTONCES volviendo a hacer las cosas difíciles "? Tomó la misma cantidad de tiempo que se muestra arriba (aunque he inspeccionado una porción muy pequeña de datos, pero ¿debería importar eso?).

gddrescue ofrece el modificador -r , que debería controlar la cantidad de relecturas en un "sector defectuoso", sin embargo, dd parece estar ejecutándose con el -r0 todo el tiempo (ya que tomó el mismo tiempo). Entonces, ¿esta opción es simplemente para "procesamiento posterior"? Lo que quiero decir es que originalmente dd y gddrescue parecen estar funcionando con -r0 y dd no parece estar masticando las partes erróneas más que gddrescue (ambos parecen detenerse en un bloque malo durante 15-18 segundos más o menos, entonces, ¿cuál es el trato, cómo es gddrescue más rápido?

Además, ¿para qué sirve la opción -D (usar escrituras sincrónicas para el archivo de salida)? No he notado ninguna diferencia con respecto a algunas de las pruebas realizadas.

¿Alguien puede comentar sobre todo el asunto? Gracias.

Respuestas:


6

No estoy seguro de cómo el autor citado llegó a su conclusión. No estoy debatiendo si es correcto o no, simplemente no tengo esa experiencia.

Por otro lado, con respecto a esta declaración ...

gddrescue es superior a dd al menos en términos de poder distinguir entre la cantidad de lecturas de disco realizadas en un sector con problemas.

La verdadera razón "al menos" para usar gddrescue es porque gddrescue no trunca la salida en intentos repetidos de lectura / escritura. gddrescue también es completamente automático, en lo que respecta a ciertos errores de lectura que detendrían dd.

Por lo tanto, el autor citado puede estar en lo correcto, puede que no ... pero toda la declaración pierde el punto de gddrescue.

ACTUALIZACIÓN: diferencias detalladas entre dd y gddrescue.

dd conv = noerror, continuará después de un error, pero simplemente omitirá el bloque defectuoso. incluso agregar la opción de sincronización solo pondrá ceros en lugar de omitir. Si usa dd para hacer otra lectura usando la misma salida, simplemente sobrescribirá / perderá todo lo que recuperó anteriormente.

gddrescue, también continuará después del error. Puede recuperar un rendimiento parcial de un bloque defectuoso, y volverá atrás e intentará el bloque sector por sector. gddrescue mantendrá un registro detallado de errores, con bloques buenos, bloques malos y sector por sector de cualquier bloque malo. Si intenta realizar la lectura nuevamente, gddrescue se cortará (truncará) y agregará los datos recuperados adicionalmente.

Tenga en cuenta, incluso con ambas herramientas si un bloque completo es 100% ilegible. Aún no obtendrá datos de él. gddrescue potencialmente puede obtener más datos, si algunos sectores del bloque siguen siendo legibles.


Ya veo, bueno ... En cuanto a que gddrescue es completamente automático, ¿no es dd también completamente automático con conv = noerror ? ¿Podría dar más detalles sobre "truncar resultados en intentos repetidos de lectura / escritura"? ¿Te refieres a las cosas de "post-procesamiento", cuando se ordena a gddrescue que vuelva a examinar los sectores que no se leyeron inicialmente?
XXL

Actualicé mi respuesta, para reflejar su pregunta.
JM Becker

He usado gddrescue varias veces en discos duros y medios ópticos. Su ventaja es que intenta recuperar áreas ilegibles. También puede detenerlo y volver a ejecutarlo más tarde y continuará justo donde lo dejó.
Chris Thompson

1
@TechZilla - gddrescue simplemente se salta el bloque dañado, así, al igual que dd hace. Como he escrito anteriormente, el relleno con ceros (conv = sync) es la opción exacta que falta gddrescue y que a veces es útil (con un esfuerzo adicional podría hacerlo manualmente con / dev / zero, porque tendría el registro de sectores defectuosos producidos por salida de gddrescue ). No hay diferencia entre gddrescue y dd en términos de recuperación, gddrescue no hace nada diferente a ese respecto. ¿Por qué? Porque, con el mismo tamaño de bloque , recuperarán la misma cantidad de datos.
XXL

@TechZilla: la única diferencia real es cuando la cantidad de sectores a procesar se elige por encima del tamaño de bloque . Esto le dará la capacidad de acelerar notablemente las cosas en comparación con dd , ya que dd solo puede funcionar con un tamaño de sector estático no variable. gddrescue , por otro lado, leerá primero todos los sectores que le haya indicado, pero también declarará que esos fragmentos son malos si un solo bloque en el interior es dudoso y una vez hecho esto, cambie al modo posterior inspeccionando las áreas confusas disminuyendo gradualmente el tamaño del sector hasta que alcance el tamaño mínimo de bloque
XXL

2

Dependiendo de cuándo se fabricó su disco duro y del fabricante, y de qué versión de firmware se ejecuta, con los discos duros modernos, cuando se detectan sectores defectuosos, el firmware los retira del uso y la unidad sabe omitir los sectores defectuosos. Entonces, la noción de "rescatar" un disco duro de sectores defectuosos puede ser discutible en ese sentido. La pregunta de si los sectores ahora malos alguna vez tuvieron datos válidos parece ser la solución de caso que está buscando, ¡sin juego de palabras!

Hay un software en grc.com llamado spinrite 6 que dice ser capaz de reparar discos duros con sectores defectuosos. Es un software pago, y nunca lo he probado. Vale la pena leer sobre esto, especialmente si uno está intentando "resucitar" un disco duro y realmente funciona como se describe. Las preguntas frecuentes en grc.com sobre spinrite 6 indican que hay una garantía de devolución de dinero de 30 días (y no hay una versión de prueba o gratuita). Nota: no estoy afiliado a grc.com, ni lo recomiendo para su situación. Solo sé que existe y que podría funcionar como se anuncia, simplemente no confíe en mi palabra: advertencia emptor.

Con respecto a evaluar si gddrescue "es superior" a dd al menos en términos de poder distinguir entre la cantidad de lecturas de disco realizadas en un sector con problemas, cualquier número de lecturas en un sector defectuoso (ya que está marcado como no sector funcional en una lista de sectores defectuosos en una lista de firmware) no me parece útil en el uso cualitativo de gddrescue o dd.

Puede ser útil leer la página web, dd (Unix) en: https://secure.wikimedia.org/wikipedia/en/wiki/Gddrescue#Recovery-oriented_variants_of_dd

También puede resultarle útil echar un vistazo a: Cómo crear una imagen de un disco duro dañado con UBCD, dd-rescue y P2 eXplorer en: http://www.myfixlog.com/fix.php?fid= 21

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.