Me gustaría poder capturar y validar sumas de verificación para colecciones de archivos a gran escala, generalmente anidadas dentro de una jerarquía de directorios compleja.
¿Cada archivo necesita una suma de verificación? ¿Hay formas de aprovechar la estructura de directorios existente para, por ejemplo, validar solo un nodo en el árbol de archivos y no necesariamente todos los archivos que contiene?
Respuesta1
La forma más eficaz de utilizar sumas de comprobación es hacer que la computadora lo haga todo. Utilice un sistema de archivos como ZFS que suma sumas de verificación (en realidad usa hashes, que son más fuertes que una suma de verificación) todos los datos cuando se escriben y los verifica cada vez que se leen. Por supuesto, la desventaja es que ZFS no sabe cuándo eliminar o sobrescribir un archivo es un error y cuándo es una operación normal, pero debido a que ZFS usa semántica de copia en escritura para todo, puede usar su función de toma de instantáneas para mitigar el riesgo. .
ZFS también puede restaurar automáticamente los datos que no pasan una verificación de hash utilizando cualquier redundancia que haya configurado, ya sea paridad estilo raid5, espejos de unidades o copias duplicadas (agregue la propiedad copias=N a cualquier sistema de archivos ZFS y almacenará N copias de cualquier dato que escribas). También almacena los hash en un árbol Merkle, donde el valor hash de un archivo depende de los hash de los bloques, el hash de una entrada de directorio depende de los valores hash de los archivos y directorios que contiene, el hash de un sistema de archivos depende en el hash del directorio raíz, etc.
Independientemente de la solución que elija, invariablemente encontrará que el proceso está limitado por la velocidad de sus discos, no por la velocidad de su CPU.
Además, no olvide tener en cuenta la BER de sus discos. Después de todo, son meras placas de óxido que giran. Una unidad de nivel de consumidor tiene una tasa de error de 1 bit leído incorrectamente por cada 10^14 bits leídos, lo que equivale a 1 bit por cada 11 terabytes leídos. Si tiene un conjunto de datos de 11 terabytes y calcula el hash de cada archivo que contiene, habrá calculado una de esas sumas de comprobación incorrectamente y habrá dañado permanentemente un bloque de uno de los archivos del conjunto de datos. ZFS, sin embargo, conoce el hash de cada bloque que escribió en cada disco de su grupo y, por lo tanto, sabe qué bloque se perdió. Luego puede usar la redundancia (paridad, espejos o copias adicionales) en su grupo para reescribir los datos en ese bloque con los valores correctos. Estas características de seguridad también se aplican cuando utiliza zfs send oceived para copiar datos desde su sistema principal a las copias de seguridad.
Sin embargo, Ben plantea un buen punto en los comentarios. ZFS no expone al usuario ninguno de los valores hash que calcula, por lo que los datos que entran o salen de un sistema ZFS deben ir acompañados de hashes. Me gusta la forma en que Internet Archive hace esto con un archivo xml que acompaña a cada elemento del archivo. Verhttps://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xmlcomo ejemplo.
Respuesta2
Quizás este sea un buen momento para mencionarEmbólsalo. Se trata de un formato de empaquetado de archivos muy sencillo pero potente destinado al archivado, la preservación a largo plazo y la transferencia de objetos digitales. Los usuarios incluyen la Biblioteca del Congreso y la Biblioteca Digital de California.
Una herramienta BagIt (existen en varios lenguajes de programación) coloca sus archivos en una estructura de directorio determinada y realiza la suma de verificación/hash por usted. Eso es todo.
PD: Por supuesto, las herramientas BagIt también pueden verificar las bolsas con las sumas de comprobación/hashes incluidas, y usted puede agregar algunos metadatos a las bolsas. Pero eso es lo más complejo que pueden llegar a ser las bolsas.
Respuesta3
Generaría una suma de comprobación para cada archivo. Las sumas de verificación son muy pequeñas y generar sumas de verificación para todo el directorio requeriría que también procese cada archivo (al menos si no está hablando de sumas de verificación de directorio, hechas solo a partir de entradas de directorio; yo también las haría para garantizar que no haya datos). esta borrado).
Suponga que tiene una suma de verificación para todo el archivo. Sabe que los datos están dañados, pero no sabe si se trata de un solo archivo y, lo que es más importante, cuál de ellos. Tener sumas de verificación separadas le brinda más flexibilidad. Puede detectar un solo archivo que esté dañado y reemplazarlo desde el archivo de otra copia de seguridad (que, a su vez, puede tener otro archivo dañado).
De esa manera, es más probable que sus datos sobrevivan.
Respuesta4
Revisé las respuestas y, aunque me gusta la idea de confiar en ZFS para manejar los errores de la capa de datos, todavía existe el problema de que los archivos se modifiquen, ya sea por error o maliciosamente. ZFS no lo protegerá en ese caso y, como alguien más mencionó, no le brindará un "hash" visible para el usuario para almacenarlo en otro lugar para validación externa.
Hay una aplicación de Linux llamada TripWire que se usó ampliamente para monitorear los ejecutables del sistema, para validar que no hayan sido modificados después de un ataque. Aparentemente ese proyecto ahora está abandonado, pero hay uno nuevo llamado AIDE (Advanced Intrusion Detection Environment), recomendado en ServerFault:
https://serverfault.com/questions/62539/tripwire-and-alternatives
Cuando lo instale, se ejecutará cada x minutos, será configurable por el usuario y verificará todas las carpetas que especifique en busca de cambios en los archivos. Debe ejecutarse una vez para calcular todos los hashes del archivo y luego, verifica todos los hashes con el archivo actual y se asegura de que sigan siendo los mismos. Puede especificar qué tipo de hash o combinación de hash usar (no recomendaría nada más débil que SHA-256), qué atributos de archivo usar (contenido, tamaño, marca de tiempo modificada, etc.), la frecuencia con la que verifica, cómo/dónde almacenar la base de datos hash, etc.
Algunos podrían considerar esto excesivo, pero dependiendo de los requisitos del OP, podría darle más tranquilidad de que los datos que está almacenando permanecerán igual después de un cierto período de tiempo.