¿Hace dd algún tipo de verificación?

Estoy usando ddpara copiar datos de un disco duro viejo a uno nuevo. Quiero asegurarme de que la integridad de los datos sea segura.

Sobre esta respuesta , Gilles dice

Si [dd] finalizó con éxito, la copia de seguridad es correcta, salvo una falla de hardware ...

¿Qué significa eso exactamente? ¿ ddTiene algún tipo de verificación incorporada?

Si tuviera que usar rsync en su lugar, también ejecuto un segundo pase --checksumpara verificar. ¿Está justificado ese tipo de paranoia?

ddo cualquier otra aplicación no tiene "algún tipo de verificación integrada" en el sentido en que probablemente esté pensando: no vuelve a leer los datos del medio de almacenamiento para compararlos con lo que se escribió. Ese es el trabajo del sistema operativo.

Realmente no es posible hacer una verificación de lectura hasta el hardware desde una aplicación. Funcionaría en algunos escenarios, pero en la mayoría de los casos no lograría nada. La aplicación podría leer lo que acaba de escribir si está escribiendo directamente en un medio de almacenamiento , pero eso normalmente se leería desde un caché en memoria, lo que no daría ninguna garantía útil. En el ejemplo que cita , ddestá escribiendo en una tubería, y en ese caso no tiene control sobre lo que sucede con los datos más adelante. En su ejemplo de rsync, una segunda pasada dersync --checksum no tiene sentido: en teoría podría detectar un error, pero en la práctica, si ocurre un error, entonces el segundo pase probablemente no informará nada malo, por lo que está desperdiciando el esfuerzo en algo que en realidad no brinda una garantía útil.

Sin embargo, las aplicaciones no verifican lo que ocurre con los datos, en el sentido de que se compruebe que el sistema operativo tiene la responsabilidad aceptada para los datos. Todas las llamadas al sistema devuelven un estado de error. Si una llamada del sistema devuelve un estado de error, la aplicación debe propagar ese error al usuario, generalmente mostrando un mensaje de error y devolviendo un estado de salida distinto de cero.

Tenga en cuenta que ddes una excepción: dependiendo de los parámetros de la línea de comando, ddpodría ignorar algunos errores . Esto es extremadamente inusual: ddes el único comando común con esta propiedad. Use en catlugar de dd, de esa manera, no corre el riesgo de corrupción y puede ser más rápido .

En una cadena de copia de datos, pueden surgir dos tipos de errores.

• Corrupción: se voltea un poco durante la transferencia. No hay forma de verificar esto a nivel de aplicación, porque si eso sucede, se debe a un error de programación o error de hardware que es muy probable que cause la misma corrupción al leer de nuevo. La única forma útil de verificar que no haya ocurrido tal corrupción es desconectar físicamente los medios e intentar nuevamente, preferiblemente en una computadora diferente en caso de que el problema fuera con la RAM.
• Truncamiento: todos los datos que se copiaron se copiaron correctamente, pero algunos de los datos no se copiaron en absoluto. Éste es digno de la comprobación a veces, dependiendo de la complejidad del comando. No necesita leer los datos para hacer eso: solo verifique el tamaño.

No, ddno hace una verificación explícita. Si desea / necesita una copia verificada forense de su disco o cualquier parte del mismo, use dcfldduna versión mejorada de la dddesarrollada por el Laboratorio forense informático del Departamento de Defensa de los EE. UU.

La única forma de estar "seguro" es hacer un pase adicional de lectura y comparación (después de descartar cachés).

Aparte de eso, dddetecta errores de lectura y escritura de la misma manera que todos los demás programas ... funciona si las unidades (y otros componentes involucrados) informan errores; para unidades que aceptan datos silenciosamente sin escribirlas, no tiene suerte.

¿Está justificado ese tipo de paranoia?

Si no puede confiar en que su hardware sea confiable, las cosas se complican ...

Sí, el hardware defectuoso puede insertar bits de error aleatorio en los datos a una velocidad de un bit por número de megabytes, esto es posible y a veces se lleva a cabo en la práctica.

Por lo general, uso md5 o sha1 hash para verificar que los datos estén intactos, releyendo tanto el origen como el destino, por ejemplo:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

Esto supone que los datos son mucho más grandes que la memoria caché del sistema de archivos, de lo contrario, es posible que deba reiniciar el sistema para verificar los datos reales en el medio y no el contenido de la memoria caché, o utilizar otro sistema para ello.

De man dd:

Cuando finaliza, dd muestra el número de bloques de entrada y salida completos y parciales, registros de entrada truncados y bloques de intercambio de bytes de longitud impar a la salida de error estándar.

Un bloque de entrada parcial es aquel en el que se leyó menos que el tamaño del bloque de entrada. Un bloque de salida parcial es aquel en el que se escribió menos del tamaño del bloque de salida. Los bloques de salida parcial a dispositivos de cinta se consideran errores fatales. De lo contrario, se escribirá el resto del bloque. Los bloques de salida parcial a dispositivos de caracteres producirán un mensaje de advertencia.

ddverifica que los tamaños de bloque de entrada / salida coincidan cada vez que copia un bloque. Si no lo hacen, maneja el error con una advertencia o error fatal (anulado con noerror). Por eso ddfunciona prácticamente todo el tiempo.

Aún así, no reemplaza la verificación manual de la integridad de su disco. Si la información es valiosa para usted, entonces sí, su paranoia está justificada . Ejecute una verificación manual una vez que ddhaya terminado.