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.

3 Comentarios.

  1. José Carlos Morillo

    Muy interesante esta información. Gracias

  2. Buen día, me gustaría saber si pueden ayudarme con una duda que tengo. Estoy trabajando en la implantación de Dspace y me han consultado sobre si Dspace guarda los datos en formato .xml o dónde los guarda. No he encontrado información con respecto a eso, sé que tiene una base de datos pero no he podido encontrar los metadatos de las colecciones de prueba que he cargado. He visto también que los metadatos pueden exportarse en formato CSV, pero no hay otra forma de levantar esos metadatos? por la base de datos tal vez? desde ya agradezco su atención, saludos.

    • Emilio Lorenzo

      Buen día, Pao…
      Dspace es extremadamente “insensible” a los datos enviados para su archivo, o por decirlo de otra manera, es “agnóstico” en cuanto al formato de los datos enviados….
      cualquier ristra de bits es almacenada para su preservación en DSpace. Este almacenamiento, “tal cual”, se efectúa en el “assetstore” (vea las entradas al respecto en este mismo blog).
      Por otra parte, la descripción (o metadatación) del objeto se almacena en una Base de Datos (PostgreSQL u Oracle)…
      Tenemos entonces que los metadatos se almacenan en la base de datos y los ficheros propiamente dichos (bitstreams) se almacenan en el assetstore.

      Y sobre estos dos componentes, Dspace ofrece una variedad de sistemas de exportación (y de importación) diversos. Usted menciona la exportacion de metadatos en CSV, pero también puede crear paquetes AIP y DIP mediante el packager exporter, y algún otro sistema.

      Podrá encontrar información completa en las siguientes páginas:

      espero haberle orientado algo, pero si tiene algunaduda adicional, no dude en contactarnos

      Emilio