Lo estoy usando ddpara copiar datos de un disco duro antiguo a uno nuevo. Quiero estar seguro de que la integridad de los datos esté segura.
En esterespuesta, dice Gilles
Si [dd] finalizó exitosamente, entonces la copia de seguridad es correcta, salvo que haya una falla de hardware...
¿Qué significa eso exactamente? ¿ ddTiene algún tipo de verificación incorporada?
Si tuviera que usar rsync en su lugar, --checksumtambién ejecuto una segunda pasada para verificar. ¿Está justificado ese tipo de paranoia?
Respuesta1
ddo cualquier otra aplicación no tiene “algún tipo de verificación integrada” en el sentido en el que probablemente estás pensando: no lee los datos del medio de almacenamiento para compararlos con lo que se escribió. Ese es el trabajo del sistema operativo.
Realmente no es posible realizar una verificación de lectura en 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. Enel ejemplo que citas, 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 rsync --checksumno tiene sentido: en teoría, podría detectar un error, pero en la práctica, si ocurre un error, entonces la segunda pasada probablemente no informará nada incorrecto, por lo que está desperdiciando esfuerzo en algo que en realidad no da una seguridad útil.
Sin embargo, las aplicacioneshacerverifican lo que sucede con los datos, en el sentido de que verifican que el sistema operativo ha aceptado la responsabilidad de los datos. Todas las llamadas al sistema devuelven un estado de error. Si una llamada al 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. Usar caten lugar dedd , de esa manera no correrá el riesgo de corrupción ypuede que sea más rápido.
En una cadena de copia de datos pueden surgir dos tipos de errores.
- Corrupción: un bit se voltea 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 de hardware que es muy probable que cause la misma corrupción al volver a leer. La única forma útil de verificar que no se haya producido tal corrupción es desconectar físicamente los medios y volver a intentarlo, preferiblemente en una computadora diferente en caso de que el problema estuviera en la RAM.
- Truncamiento: todos los datos que se copiaron se copiaron correctamente, pero algunos de los datos no se copiaron en absoluto. ÉsteesVale la pena comprobarlo a veces, dependiendo de la complejidad del comando. No necesitas leer los datos para hacer eso: simplemente verifica el tamaño.
Respuesta2
No, ddno hace una verificación explícita. Si desea o necesita una copia verificada forense de su disco o de cualquier parte del mismo, utilice dcflddla que es una versión mejorada dddesarrollada por el Laboratorio de Informática Forense del Departamento de Defensa de EE. UU.
Respuesta3
La única forma de estar "seguro" es realizar una pasada adicional de lectura y comparación (después de eliminar los cachés).
Aparte de eso, dddetecta errores de lectura y escritura de la misma manera que lo hacen todos los demás programas... funciona si las unidades (y otros componentes involucrados) informan errores; para las unidades que aceptan datos silenciosamente sin escribirlos, no tiene suerte.
¿Está justificado ese tipo de paranoia?
Si no puede confiar en que su hardware sea confiable, las cosas se complican...
Respuesta4
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 en la salida de error estándar.
Un bloque de entrada parcial es aquel en el que se leyó un tamaño menor que el del bloque de entrada. Un bloque de salida parcial es aquel en el que se escribió un tamaño menor que el del bloque de salida. Los bloqueos parciales de salida a dispositivos de cinta se consideran errores fatales. De lo contrario, se escribirá el resto del bloque. Los bloqueos parciales de salida a dispositivos de caracteres producirán un mensaje de advertencia.
ddverifica que los tamaños de los bloques de entrada/salida coincidan cada vez que copia un bloque. Si no es así, maneja el error con una advertencia o un 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í,tu paranoia está justificada. Ejecute una verificación manual una vez ddfinalizada.