Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
Preservación e integridad de ficheros en DSpace | Hablando de DSpace

Preservación e integridad de ficheros en DSpace

La preservación y la integridad de los ficheros almacenados en un sistema Dspace preocupan con frecuencia, y con razón, a los gestores de los repositorios. Intentaremos despejar las dudas más frecuentes sobre el comportamiento del software DSpace al respecto.

Una función hash es, básicamente, un algoritmo criptográfico que aplicado a un fichero produce como resultado una cadena alfanumérica única, permitiendo determinar, por comparación con valores anteriores de la cadena,  los cambios en el mismo, la integridad del fichero. DSpace realiza el  cálculo del valor hash de cada fichero almacenado en el sistema, incluidos los ficheros de licencia, etc.. Cuando se sube un fichero (en los cambios de estado submitted, approved y made available), se calcula automáticamente su valor hash, almacenándose en la tabla de bitstreams:

arvo.pdf   checksum: d4c4979a5f4f34f6158a2620f0d5710c (MD5)

license_rdf   checksum: 603b6a1a20b0b67b338ea745cbacb74f (MD5)

¿Y qué sucede entonces ante la modificación de un fichero? Para responder a esta pregunta, en primer lugar debemos aclarar que en DSpace un fichero en realidad no se modifica, sino que se sustituye por otro diferente (borrándose el antiguo o versionándolo) calculándose automáticamente el hash del nuevo fichero y generándose una nueva entrada en la tabla de bitstreams. Con este proceso se asegura que la integridad de cada fichero queda reflejada en la tabla bitstreams.

Parte de esta información se graba adicionalmente en el metadato dc.description.provenance. Importante tener en cuenta que este metadato sólo se graba en la subida inicial del fichero, no en las acciones de borrado o sustitución de fichero que pudieran ser realizadas posteriormente por un administrador.

dc.description.provenance Submitted by xxxxxx  (name@mail.com) on 2008-02-11T11:46:16Z No. of bitstreams: 1 RSCAS_DL_2005.pdf: 185727 bytes, checksum: 4d46d9280e930bf6a024f6d39f3a74bb (MD5)

Existe además el comando checker  (cuya ejecución se programa normalmente a intervalos regulares mediante crons) que permite comprobar que los hash de los ficheros no han cambiado y cuyo resultado y fecha de ejecución se almacenan en la tabla ckecksum_history:

[dspace]/bin/dspace checker

Adicionalmente, podríamos reseñar que en los logs de DSpace se registran las acciones realizadas sobre los bitstreams (añadir nuevos y borrar los existentes) y los usuarios que las han realizado. Pero hay que señalar que interpretar los logs directamente es una tarea bastante ardua que requiere del análisis de ingentes cantidades de datos sobre la historia/logs del repositorio. Una vía que no nos atreveríamos a recomendar.

En caso de detectarse la alteración o algún problema con un fichero, se deberá recurrir a un backup del assetstore  (o mas infrecuentemente, backups AIP).  Este no es un proceso de DSpace propiamente dicho, sino de las políticas de recuperación de cada repositorio. Cada repositorio deberá plantearse los modos y medios de recuperación de la información ante eventuales pérdidas.

Finalmente, señalar que DSpace no comprueba la existencia de virus en los ficheros de forma estándar, pero mediante la implantación de módulos específicos es posible analizar los ficheros del repositorio en busca de virus, avisando a publicadores y administradores de potenciales riesgos en sus ficheros y eventualmente restringiendo el archivo de los mismos.

Los comentarios están cerrados.