¿Cómo genero y valido eficientemente sumas de verificación de archivos?

Me gustaría poder capturar y validar sumas de comprobació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 dentro?

La forma más eficiente de usar sumas de verificación es hacer que la computadora lo haga todo. Use un sistema de archivos como ZFS que compruebe (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 los datos. Por supuesto, la desventaja es que ZFS no sabe cuándo eliminar o sobrescribir un archivo es un error y cuándo es su funcionamiento normal, pero debido a que ZFS utiliza una semántica de copia en escritura para todo, puede usar su función de captura de imágenes para mitigar el riesgo .

ZFS también puede restaurar automáticamente los datos que fallan en una comprobación de hash utilizando cualquier redundancia que haya configurado, ya sea paridad de estilo raid5, duplicados de unidad o copias duplicadas (agregue la propiedad copias = N a cualquier sistema de archivos ZFS y almacenará N copias de cualquier dato que escriba). También almacena los hash en un árbol Merkle, donde el valor de hash de un archivo depende de los hash de los bloques, el hash de una entrada de directorio depende de los valores de 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 tenga, siempre 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. Son, después de todo, meros platos de óxido giratorio. Una unidad de nivel de consumidor tiene una tasa de error de 1 bit de lectura incorrecta por cada 10 ^ 14 bits de lectura, lo que equivale a 1 bit de cada 11 terabytes que lee. Si tiene un conjunto de datos de 11 terabytes y calcula el hash de cada archivo en él, habrá calculado una de esas sumas de verificación de forma incorrecta y dañado de forma permanente un bloque de uno de los archivos en el conjunto de datos. Sin embargo, ZFS 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.

Sin embargo, Ben menciona un buen punto en los comentarios. ZFS no expone ninguno de los valores hash que calcula al usuario, por lo que los datos que ingresan o salen de un sistema ZFS deben ir acompañados de hash. Me gusta la forma en que Internet Archive hace esto con un archivo xml que acompaña a cada elemento del archivo. Ver https://ia801605.us.archive.org/13/items/fakebook_the-firehouse-jazz-band-fake-book/fakebook_the-firehouse-jazz-band-fake-book_files.xml como ejemplo.

Generaría suma de verificació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 proceses todos los archivos (al menos si no estás hablando de la suma de verificación del directorio, hecha solo a partir de entradas de directorio, también las haría, para asegurar que no haya datos esta borrado).

Suponga que tiene una suma de verificación para todo el archivo. Usted sabe que los datos están dañados, pero no sabe si este es solo un 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 del 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.

Tal vez este es un buen momento para mencionar BagIt . Este es un formato de empaque de archivo muy simple pero potente destinado al archivo, 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 determinada estructura de directorio y realiza la suma de comprobación / hashing por usted. Eso es todo.

PD: Por supuesto, las herramientas BagIt también pueden verificar las bolsas contra las sumas de comprobación / hashes incluidos, y puede agregar algunos metadatos a las bolsas. Pero eso es tan complejo como las bolsas.

Esta respuesta es una combinación de la de @ lechlukasz y @ db48x , que también incorpora algunos puntos hechos en los comentarios, así como algunos de mis propios pensamientos.

El camino simple hacia adelante es un enfoque combinado de sistema de archivos y metadatos separados.

Al utilizar un sistema de archivos que realiza el hash y la validación de datos sobre la marcha, como ZFS o Btrfs (tenga en cuenta que aunque se han hecho grandes avances, Btrfs no se considera listo para el uso de producción en este momento), puede estar razonablemente asegúrese de que si los datos se pueden leer del disco sin que el sistema operativo produzca errores, la lectura de datos se escribió en el disco de la manera prevista por el sistema de archivos. Al ejecutar operaciones periódicas de "fregado", todos los datos se leen y verifican contra la idea del sistema de archivos de lo que debería ser.

Sin embargo, eso solo protege contra la corrupción en el disco (bloques ilegibles, errores de escritura de hardware, escrituras inválidas que corrompen partes de los datos directamente en el dispositivo de bloque, etc.). No protege contra un error de software, operación incorrecta del usuario o software malicioso que funciona a través de las instalaciones del sistema operativo para trabajar con archivos, suponiendo que esas instalaciones estén libres de tales errores.

Para protegerse contra este último, necesita otra capa de protección. Los datos de suma de comprobación o hash desde la perspectiva de una aplicación de usuario ayudarán a proteger contra muchos de los riesgos mencionados anteriormente, pero deben realizarse por separado (ya sea como una acción de proceso incorporada en el software o como un proceso completamente separado).

Con el hardware actual y lo que es práctico para almacenar grandes cantidades de datos (discos duros de disco giratorio en lugar de discos de estado sólido / SSD), incluso los algoritmos de hash complejos como SHA1 estarán en gran medida vinculados a E / S, es decir, la velocidad en el que los datos se procesan en función del hash será una función de la velocidad de lectura del sistema de almacenamiento, en lugar de la capacidad del procesador de la computadora para calcular el hash. Hice un experimento ejecutando un proceso de hash MD5 en el espacio de usuario de aproximadamente 150 GB de datos sobre lo que en 2012 era una PC de consumo de nivel medio, y terminó después de ejercer el disco básicamente sin interrupción durante unos 40 minutos. Al aumentar esas cifras hasta 100 veces, obtendría los hash MD5 de una colección de 15 TB en aproximadamente tres días en ese mismo hardware. Al agregar la velocidad de transferencia de lectura (que se puede lograr fácilmente, p. Ej.RAID 0, por ejemplo, es una franja sin redundancia, comúnmente utilizada para lograr un mayor rendimiento de lectura / escritura, posiblemente en combinación con RAID 1 formando RAID 10 ), el tiempo de finalización puede reducirse para la misma cantidad de datos.

Al combinar los dos, obtienes lo mejor de ambos mundos: el sistema de archivos te garantiza que lo que recibiste al leer el archivo es lo que realmente se escribió, y un proceso de comprobación de la fijación por separado puede ejecutarse en toda la colección para garantizar que los datos almacenado aún coincide con lo que se ingirió en el archivo. Cualquier inconsistencia entre los dos (el sistema de archivos dice que el archivo está bien, la comprobación de la fijación dice que no) indicará un archivo que ha sido modificado fuera del modo de operación previsto del archivo pero desde dentro de las instalaciones del sistema operativo, lo que provocará una restauración desde un secundario copia (copia de seguridad). Por lo tanto, la comprobación de la fijación puede ejecutarse en un intervalo de tiempo más largo, que se vuelve esencial para archivos muy grandes, pero se garantiza que los accesos en línea no se corromperán en el hardware si las lecturas tienen éxito. En principio, el software de archivo podría confiar en el sistema de archivos para informar inconsistencias como errores de lectura, y realizar una verificación de fijación por separado en segundo plano, ya que el usuario está trabajando con el archivo y muestra un mensaje apropiado si eso indica que el archivo no coincide con lo que se ingirió en el archivo Al utilizar un sistema de archivos de hash de bloques, dicho esquema tendría un impacto mínimo en el rendimiento percibido y al mismo tiempo garantizaría que el contenido es correcto.

He revisado 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 cambien, ya sea por error o maliciosamente. ZFS no lo protegerá en ese caso, y como alguien más lo mencionó, no le dará un "hash" visible para el usuario para almacenar en otro lugar para la validación externa.

Hay una aplicación de Linux llamada TripWire que se utilizó ampliamente para monitorear los ejecutables del sistema, para validar que no se hayan cambiado después de un ataque. Aparentemente, ese proyecto ahora está abandonado, pero hay uno nuevo llamado AIDE (Advanced Intrusion Detection Environment), recomendado en ServerFault:

/server/62539/tripwire-and-alternatives

Cuando lo instale, se ejecutará cada x minutos, configurable por el usuario, y verificará todas las carpetas que especifique para los cambios en los archivos. Debe ejecutarse una vez para calcular todos los valores hash del archivo, y luego, comprueba todos los valores hash 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, fecha y hora modificada, etc.), la frecuencia con la que verifica, cómo / dónde almacenar la base de datos hash, etc.

Algunos podrían considerar esta exageración, 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 punto de tiempo.

Los Archivos Nacionales de Australia han desarrollado [Checksum Checker] ( http://checksumchecker.sourceforge.net/ ) que está disponible gratuitamente bajo GPLv3.

Lee una suma de verificación y un algoritmo de una base de datos, luego vuelve a calcular la suma de verificación para el archivo, compara los dos valores e informa si hay un error. Es compatible con los algoritmos MD5, SHA1, SHA2, SHA256 y SHA512.

Otro software en su repositorio digital [DPR] ( http://dpr.sourceforge.net/ ) genera la suma de verificación inicial (además de realizar todas las demás actividades de procesamiento)