Almacenamiento distribuido y preservación digital: una panorámica de alternativas

José Manuel Castillo

Universitat Autònoma de Barcelona

Ferran Jorba

Universitat Autònoma de Barcelona

Archiving should be done by
librarians and archivists,
period. Gordon Tibbitts,
Blackwell Publishing¹

Resumen [Resum] [Abstract]

De los diversos aspectos de la preservación digital, este artículo se centra en uno: el almacenamiento distribuido (creación de réplicas) como garantía de que al menos no se pierda, corrompa o sea inaccesible una única copia de los documentos.

Miraremos cómo replican sus datos Internet Archive y Google, y evaluamos algunas de las herramientas de sofware que hemos encontrado, tanto las específicamente bibliotecarias (en especial LOCKSS), las propietarias orientadas al archivado empresarial, y algunas de las opciones de software libre.

El artículo se detiene sobretodo en LOCKSS, ya que se ha creado un nombre como la solución estandarizada para preservación digital en el mundo bibliotecario, pero que a nosotros nos decepcionó por su poca claridad en sus objetivos e implementación, y sus requerimientos excesivos. Dado que de estas herramientas evaluadas, ninguna sirve para preservar (replicando) nuestros fondos, aportamos nuestra solución interina y líneas futuras de investigación.

1 Introducción y motivación

Este artículo es una primera recapitulación de lo que hemos encontrado en la UAB sobre sistemas informáticos de preservación digital basados en múltiples copias distribuidas. Naturalmente, un sistema distribuido, por su propia definición, requiere de la participación de múltiples socios y, por tanto, este resumen no deja de ser sino una pequeña contribución a una estrategia consorciada de preservación digital.

Intentar concretar las distintas soluciones implementables que existen sobre este tema no nos ha resultado fácil, porque estamos en una etapa en la que todavía existe una gran cantidad de teoría académica, formalismos teóricos y aplicaciones en sus primeras etapas de desarrollo, que todavía no han podido demostrar su viabilidad. Estamos seguros, además, de que existen opciones más imaginativas que no hemos explorado todavía.

En cualquier caso lo cierto es que, en el entorno de las bibliotecas y universidades, todos nos encontramos en una situación parecida:

Comenzamos a tener repositorios digitales, algunos propios y otros compartidos.

Comenzamos a tener volumen, unos más, otros menos; pero sumándolos, ya hablamos de terabytes.

Algunos de estos documentos son únicos, otros son muy costosos o imposibles de repetir: es patrimonio que hemos de preservar.

Solos no podemos abordar el problema; nadie podrá hacerlo solo, tenemos que ayudarnos mutuamente.

Tenemos pues que diseñar una estrategia conjunta.

Los lectores familiarizados en preservación digital se estarán preguntado por qué estamos evaluando distintas soluciones si ya existe LOCKSS (Lots of Copies Keep Stuff Safe). Hablaremos de ello un poco más adelante.

2 Líneas generales de la preservación digital

Conviene aclarar que estamos hablando del estadio más básico de la preservación digital, el llamado bit-level preservation, es decir, el de garantizar que los objetos, ficheros o documentos no sean alterados. Generalmente, las diferentes implementaciones que hemos encontrado y evaluado se basan en estos principios:

Hay que tener más de una copia de cada fichero o conjunto de ficheros, y en ordenadores distintos. Cuantas más copias, mejor. LOCKSS recomienda un mínimo de 6, preferiblemente 7.

Debido al volumen de información, y teniendo en cuenta ventajas e inconvenientes, se considera que es mejor no mantener copias en cinta de los ficheros a preservar. Las ventajas de dicha política son: una mayor facilidad para realizar las réplicas de los datos a preservar y una mayor velocidad de acceso y transferencia. Actualmente los discos duros han crecido hasta una capacidad de un terabyte a finales de 2007 y tienen un coste económico por GB comparable al de una cinta, con la ventaja de permitir los primeros una mayor flexibilidad y mejores prestaciones en cuanto a acceso aleatorio.

Estas copias tienen que estar de alguna manera en línea, porque es la única manera de verificar que son idénticas y, por tanto, no alteradas. No es posible verificar automáticamente una cinta de backup, un CD o un DVD que no esté en línea.

Buena parte de las soluciones que hemos encontrado se basan en unidades de almacenamiento (ordenadores) autónomos, con su sistema operativo (casi siempre Linux o, en el caso de LOCKSS, OpenBSD) y su sistema de replicación, verificación y reparación en el propio sistema. No se trata de discos en un armario de discos genérico, sino de ordenadores con disco (típicamente mucho disco).

Todo el mundo recomienda la dispersión geográfica de los sistemas, tanto como sea posible, para minimizar el impacto que pueda provocar un incidencia física, humana, económica u organizativa en un lugar concreto: si todos los ordenadores están juntos, un incendio, inundación, terremoto o cualquier otro desastre conllevaría la pérdida de todas las copias para siempre.

3 Tipos de soluciones

Nos encontramos en un momento en que al menos tres comunidades diferentes necesitan unas soluciones similares y han llegado a conclusiones del mismo tipo. Seguramente en el mundo bibliotecario parece que sólo exista LOCKSS, que tiene el prestigio enorme de un proyecto pionero, y además con mucha presencia y literatura publicada, pero hay vida más allá de LOCKSS y, de hecho, si hemos mirado más allá de LOCKSS ha sido por una cierta frustración con este sistema.

Paralelamente, el mundo empresarial-corporativo, especialmente en Estados Unidos, también tiene la necesidad (y a menudo la obligación legal) de almacenar documentos durante largos períodos de tiempo: éste es uno de los problemas causados por la mítica «oficina sin papel». Terminológicamente, los proveedores de soluciones empresariales tienden a utilizar la expresión fixed content, y se refieren a toda la documentación, a menudo administrativa que, una vez generada, no se modifica y se consulta poco o nunca, aunque tengan que conservar, incluso algunas durante períodos respetables de tiempo, como por ejemplo las historias clínicas o, cuando no, sencillamente el hecho de que resulta cada vez más imprescindible para el desarrollo de su actividad el archivar y mantener al menos parte del enorme volumen de datos que se generan actualmente.

Finalmente, en la informática de consumo, la manipulación cada vez mayor de ficheros multimedia (audio y video), especialmente en servidores de uso compartido, ha creado la necesidad de gestionar estos volúmenes de manera diferente a como se hacía hasta ahora (backups en cinta).

Hoy en día, en muchos entornos, los responsables del departamento de informática se cuestionan si vale la pena hacer copias de seguridad en cinta. Cada vez más, las soluciones de backup en disco, o en general, las de almacenamiento nearline (entre el online del disco en producción y el offline de la cinta) tienen una mayor implantación en el mercado.

4 Lecciones de los grandes sistemas en Internet

Antes de entrar a valorar las soluciones que hemos evaluado, vale la pena echar un vistazo a cómo custodian sus datos algunos de los grandes sistemas de Internet.

4.1 Internet Archive

De las grandes instalaciones en Internet, Internet Archive es el que más se parece a nuestro caso, ya que uno de sus objetivos principales es el de preservar webs. Internet Archive ha desarrollado un sistema más bien minimalista para configurar los nodos de sus servidores de disco.² Para garantizar la integridad de sus copias, Internet Archive tiene tres centros de datos: uno en San Francisco, otro en Amsterdam y otro más en El Cairo, y replican los ficheros vía rsync,³ aunque guardando una copia de las versiones cambiadas o borradas.⁴ Como dicen sus responsables, se trata de buscar un sistema barato,⁵ sencillo y efectivo. Los responsables de Internet Archive recalcan que los errores humanos también producen pérdidas, de manera que es mejor tener equipos con personal diferente para sus distintos centros.⁶ En su momento habían tenido malas experiencias con la recuperación masiva de cintas DLT, con lo que han llegado a la conclusión de que es mejor tenerlo en disco, y cuanto más vivo mejor. Tanto es así que han creado una empresa, Capricorn Tech,⁷ la cual comercializa su diseño de servidor de disco llamado Petabox,⁸ que utilizan en sus centros y en otras instituciones, como la Biblioteca Nacional de Francia.⁹

4.2 Google

¿Cómo lo hace Google? Es sabido que Google utiliza masivamente ordenadores económicos con el sistema operativo Linux, procesando sus datos en paralelo. Google ha desarollado una infraestructura extraordinaria con la que difícilmente puede compararse cualquier universidad o biblioteca de nuestro entorno,¹⁰ pero sí que podemos aprender algunas cosas. Por la información de la que disponemos,¹¹ Google ha desarrollado su propio sistema de ficheros, llamado GFS,¹² y sus datos están replicados al menos tres veces, y cinco sus metadatos.¹³ Además de sus herramientas de búsqueda, sabemos que Google también aloja datos, ya sea correo (Gmail), fotos (Picassa), vídeos (Google video y Youtube) o, más recientemente, grandes conjuntos de datos científicos de acceso público (Palimpsest). Pero, en cualquier caso, Google tampoco hace backups en cinta.

5 Soluciones bibliotecarias

Lo que distingue específicamente al tratamiento bibliotecario al tema que nos ocupa es doble. Por un lado, que no hay ningún límite temporal (preservar "para la posteridad") y, por otro, la búsqueda de soluciones cooperativas. Ambas características forman parte de la tradición profesional, y quedan perfectamente ilustradas en la cita de Thomas Jefferson que preside LOCKSS y CLOCKSS:

"...let us save what remains: not by vaults and locks which fence them from the public eye and use in consigning them to the waste of time, but by such a multiplication of copies, as shall place them beyond the reach of accident."¹⁵

5.1 LOCKSS y CLOCKSS

Empecemos por la aplicación que en principio debería ser la solución estandarizada para la preservación: LOCKSS. LOCKSS¹⁶ es un proyecto ambicioso, muy ambicioso, y con fundadores y socios de envergadura: Stanford, Sun Microsystems, Library of Congress y The New York Public Library, entre otros centros. El principio que lo guía es muy fácil de entender: Lots Of Copies Keep Stuff Safe, es decir, muchas copias permiten que el material esté seguro. Si hoy en día podemos leer a los clásicos griegos, latinos o medievales es porque, aunque se hayan perdido muchos manuscritos, se han conservado otros tantos gracias a que había copias en distintos lugares del mundo. Se trata de aplicar este principio a los documentos digitales: multiplicar las copias de los documentos y situarlos en sedes geográficamente dispersas para garantizar que, aunque alguna se pierda o estropee, las otras permitan que ninguna obra se quede sin réplicas.

A partir de este principio básico y cargado de sentido común, la aplicación práctica de LOCKSS sorprende por sus particularidades. Como la idea original surgió a partir de la voluntad de preservar publicaciones de editores terceros,¹⁷ todo el sistema pivota alrededor de un crawler o robot que recoge las revistas remotas¹⁸ según unas reglas o plug-ins específicas para cada título. Este contenido, estas páginas web, se replican y auditan según el protocolo Library Cache Auditing Protocol (LCAP), un sistema altamente sofisticado para comparar y verificar que todas las copias se conserven íntegras y, en caso de conflicto, un sistema de votación y valoración de confianza entre todos los sistemas que forman parte de LOCKSS para determinar qué copias son la auténticas y cuáles las alteradas:¹⁹ es decir, lo que los filólogos han hecho con las ediciones críticas de toda la vida, pero a tiempo real y automatizado.

De todas maneras, cuando el contenido a preservar no es necesariamente público, o no es accesible vía web, LOCKSS no es aplicable, sino que parece que haya que utilizar un derivado que se llama CLOCKSS (Controlled o Community LOCKSS), el cual antes tenía sus páginas dentro de la web de LOCKSS pero que ahora incluso tiene su propio dominio.²⁰ De todas maneras, esta distinción continúa siendo muy difusa en sus páginas Web. Por ejemplo, en el sitio de CLOCKSS se afirma que "CLOCKSS host libraries are collecting and preserving comprehensive collections including materials to which they DO have a subscription and materials to which they DO NOT have a subscription. CLOCKSS is preserving material published by scholarly publishers."²¹ (la cursiva es nuestra). Parece ser que la única diferencia real entre uno y otro sea que LOCKSS implementa un archivo abierto (light archive) y CLOKSS cerrado (dark archive) hasta que no ocurra algún acontecimiento que permita al archivo salir a la luz.²² Finalmente, parece que no está prevista la incorporación de más de 15 bibliotecas participantes en el consorcio CLOCKSS.²³

En nuestro caso, el fondo a preservar no se trata tanto de revistas HTML externas, sino en primera instancia del patrimonio digital de nuestra universidad (los ficheros PDF de las revistas publicadas por la propia UAB y que nos proporciona el Servei de Publicacions, más los ficheros TIFF resultado de digitalizaciones retrospectivas). También tenemos, en segundo lugar, otros tipos de documentos, como fotos, vídeo, audio y otros materiales. Según hemos aprendido, en el caso de LOCKSS y CLOCKSS para casos como éstos hay que escribir unos plugins específicos adaptados a cada tipo de colección.

Sorprendentemente para una aplicación con licencia abierta que comparte con LOCKSS, a finales de 2007 no existe ningún enlace para bajar el software. En la UAB instalamos una copia (la aplicación está escrita en Java) gracias a unas instrucciones que nos enviaron en privado a partir de la consulta que les hicimos. Por otra parte, la instalación de CLOCKSS requiere abrir en nuestros ordenadores una serie de puertos TCP y UDP para que sean accesibles desde el dominio stanford.edu.

Finalmente, nos sorprendió que los requisitos para garantizar que CLOCKSS funcione correctamente son que haya un mínimo de 6 copias, preferiblemente 7, de los documentos. Si, por ejemplo, en la UAB vamos a digitalizar unos 11 TB en un año, tendríamos que disponer de entre 70 y 80 TB de disco.

Es decir que, al menos en nuestro caso, la experiencia con LOCKSS ha sido poco satisfactoria. Y por esto empezamos a buscar alternativas.

5.2 DAITSS

DAITSS²⁴ significa Dark Archive In The Sunshine State y su objetivo es la implementación integral del modelo OAIS²⁵ y, como parte del mismo, implementa replicación de objetos (por defecto 3 copias, no 7 como LOCKSS) y la migración de formatos. En todo caso, no tanto como sistema de replicación per se, que era lo que estábamos buscando, sino como parte de una solución integral que tendríamos que evaluar con otros parámetros, especialmente su compatibilidad en la integración en el flujo de trabajo de nuestros depósitos ya existentes. Está escrito en Java y MySQL, licencia GPL, y publican actualizaciones con una cierta regularidad.

5.3 koLibRI

En Alemania también hay centros de preservación digital, como Nestor,²⁶ y tienen proyectos de software como koLibRI,²⁷ escrito en Java y para la base de datos DB2, pero a pesar de su enfoque de preservación, no hemos encontrado sistemas de réplica o verificación de objetos digitales.

6 Comerciales-corporativas

Este tipo de soluciones acostumbra a poner más énfasis en aspectos como el "llaves en mano", o incluso la fiabilidad legal de sus productos, que la posibilidad de cooperar con instituciones externas para llevar a cabo una política conjunta de preservación a largo plazo.

A raíz de esta necesidad, están apareciendo en el mercado un gran número de aplicaciones para proveer una solución. Las más extendidas implementan el modelo CAS (Content-Addressable Storage);²⁸ un sistema de almacenamiento que se basa en el mecanismo de recuperación de la información en base al contenido de la misma, y no al de su ubicación física. Trabaja a nivel lógico con el concepto de objetos digitales (la información a preservar), a los que se les asocia una etiqueta (que los identificarán en el sistema) y una serie de otros metadatos. A nivel físico suele funcionar gestionando múltiples copias de los mismos objetos, almacenadas de manera lo más dispersa posible, para evitar pérdidas de información causadas por fallos humanos, del hardware o del software.

6.1 Centera

Centera²⁹ es una plataforma para el archivado de contenidos digitales invariables comercializado por EMC, procedente de la compra de la empresa FileWave en 1999,³⁰ y una de las soluciones CAS (Content-Addressed Storage) pioneras y con mayor implantación en el mercado.

Su arquitectura física (denominada por el propio fabricante como RAIN, Redundant Array of Independent Nodes) consiste en un conjunto de nodos (servidores Linux) conectados entre sí en una red de área local privada, los cuales desempeñan una de dos posibles funciones: provisión de espacio para almacenamiento (permitiendo albergar 1,38 TB netos en configuración de espejo, o 2,36 TB en protección por paridad), y conectividad por red (con un puerto Ethernet de 1 Gbps y soporte TCP/IP).

Un armario al completo de su capacidad (esto es, con 32 nodos) puede disponer de hasta aproximadamente 75 TB netos, aunque pueden conectarse tantos armarios entre sí como espacio de almacenamiento total se requiera.

El sistema "garantiza" la inmutabilidad de los contenidos que almacena. Una vez más, el principio por el que se intenta preservar la información es mediante el mantenimiento de múltiples copias más o menos dispersas. Así, periódicamente Centera se encarga de ejecutar determinados procesos para asegurar que en todo momento existen dos copias de cada objeto que se almacena, y que éstas se mantienen inmodificadas e idénticas al original introducido en el sistema inicialmente. En caso de detectarse ciertos fallos en el hardware o inconsistencias de las copias o de los metadatos, Centera posee la capacidad para recuperarse automáticamente.

¿Hasta qué punto están los datos a salvo? Si las copias de un determinado objeto digital estuvieran en sendos discos físicos que fallaran al mismo tiempo (o casi simultáneamente), y como consecuencia de ese fallo, la copia del objeto que albergaran cada uno se perdiera, no se podría recuperar la información almacenada. Esto es así tanto en una configuración de espejo (en el caso en que se perdiera concurrentemente el disco original y su espejo), como en una de protección de paridad (en el caso de perderse dos discos en la misma formación, siendo imposible recalcular la paridad simple). Por lo tanto, la recomendación del fabricante es mantener dos conjuntos de sistemas Centera replicándose entre ellos (esto es, un mínimo de cuatro copias de cada objeto digital).

Otras funcionalidades interesantes son la posibilidad de convertir en partes el espacio de los contenidos (mediante los llamados pools virtuales), definir políticas de retención de los objetos, extender la solución según las necesidades particulares a través de una API supuestamente abierta, y otros.

6.2 Assureon

Assureon de Nexsan³¹ es una solución muy similar a la que presenta EMC con Centera.

A nivel de hardware, y a diferencia de Centera, Assureon se basa en el almacenamiento de la información no en nodos independientes, sino en arrays de discos controlados por un sistema central. Los arrays de discos son los propios desarrollados por la propia empresa Nexan (SATABeast y SATABoy) y se basan en tecnología SATA.

A nivel funcional tiene dos ventajas de las que carece su competencia, como son: la posibilidad de almacenar la información en formaciones de discos de doble paridad o RAID6 (con lo que se obtiene mayor protección ante eventuales fallos de los discos), y la capacidad de servir los objetos a través de una interfaz de sistema de ficheros y acceder a ellos mediante NFS o CIFS (sin tener que trabajar forzosamente con desarrollos propios basados en APIs, ni tener que pagar la licencia por otros productos, como es el caso de Centera).

Una tercera ventaja muy importante es que el sistema dispone de un mecanismo (denominado por el propio fabricante como AutoMAID) para ahorrar energía e intentar preservar la vida útil de los discos. MAID (Multiple Array of Idle Discs) consiste en que, después de un determinado (y configurable) tiempo durante el que no se haya accedido a la información guardada en los discos, el sistema hace que: primero, se aparquen los cabezales del disco; segundo, y después de pasado más tiempo, se bajen las revoluciones a las que gira; y tercero, habiendo transcurrido más tiempo aún, se pare el disco totalmente.

Para entornos como el del objeto de nuestro estudio, los de archivado y preservación digital, en que el acceso a los datos es muy esporádico (básicamente el que hace el propio sistema para asegurarse que todo está como tiene que estar), esta función de ahorro de recursos es muy importante a la hora de considerar una solución.

6.3 CAStor

La de CAStor³², de la empresa Caringo, es una solución CAS sólo de software, a diferencia de las dos anteriores, que incluían también el hardware.

A nivel de operativa, consiste en simplemente conectar un pendrive USB a un servidor con hardware estándar (no es necesario que sea de grandes prestaciones, pero sí que disponga de gran capacidad de almacenamiento), y arrancar el sistema desde ese dispositivo. Una vez éste esté funcionando, la máquina se convierte automáticamente en un nodo integrado en la red de almacenamiento.

Cuanta más capacidad se necesite, más máquinas pueden integrarse en la red (puede escalar hasta más de 1 PB con centenares de nodos): tan sólo hace falta conectar un servidor más y hacer que arranque desde el pendrive USB con el software CAStor.

También se basa en los mismos principios que las otras soluciones: se mantienen diversas copias de los objetos almacenados y el sistema se encarga automáticamente de comprobar de forma periódica su integridad y de recuperarse después de fallos o cambios en la configuración.

7 Software libre

Linus Torvalds, creador del kernel Linux, es el autor de una frase muy citada, "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it",³³ que es una variación de la de Thomas Jefferson utilitzada por LOCKSS. Y de hecho, hay mucha experiencia acumulada durante muchos años en la réplica de repositorios de software libre, empezando por las colecciones GNU y TeX, Perl, Apache y posteriormente los más masivos de Linux.

7.1 Twisted Storage

Twisted Storage³⁴ es el primer proyecto de software libre y de código abierto que pretende implementar el modelo CAS. Está escrito en Python y utiliza el motor para aplicaciones en red Twisted,³⁵ y puede trabajar tanto con MySQL como con SQLite. Inicialmente nos pareció que era un proyecto muy interesante, ya que prometía funcionalidades de las que sólo disponían soluciones comerciales y muy costosas. Lamentablemente, sólo se ha publicado una primera versión, la 0.1.5 en octubre de 2006, y desde entonces no ha habido ningún movimiento en su desarrollo.

7.2 Allmydata-Tahoe

Allmydata³⁶ es una empresa que ofrece alojamiento de datos para particulares y empresas, con garantías de privacidad, redundancia y disponibilidad. A su vez, el desarrollo de la próxima versión de su software³⁷ es abierto y está especialmente enfocado a la descentralización, la criptografía fuerte y la redundancia. Igual que Twisted Storage, está escrito en Python, se basa en el motor Twisted para apliaciones en red y OpenSSL y otros módulos criptográficos, pero en estos momentos todavía no lo recomiendan para producción por no estar terminado todavía. En todo caso, dado que encriptar datos va contra las políticas de preservación a largo plazo (por si en el futuro se perdiese la posibilidad de desencriptarlas, ya sea por pérdida de claves o bien por otros problemas, no hubiera servido de nada su custodia) este aspecto no nos lo hace muy recomendable.

7.3 MogileFS

MogileFS³⁸ es un sistema de ficheros distribuido, especialmente diseñado como servidor de documentos en sitios web con mucho tráfico, como LiveJournal,³⁹ para el que fue escrito ya que sus responsables encontraban una solución comercial asequible. Está siendo utilizado por diversos sitios web con buen rendimiento y dispone de una buena comunidad de usuarios. Está escrito en Perl y utiliza MySQL o PostgreSQL.

Lamentablemente, no provee de ningún sistema de comprobación de la integridad de la información almacenada en el grid, aunque eso sí, permite la posibilidad de mantener múltiples copias de un mismo objeto. De la misma manera, tampoco dispone de ningún mecanismo de recuperación automática de un nodo caído. Además, en nuestra instalación de laboratorio, también observamos que presentaba algunos problemas con ficheros de más de 65MB de tamaño.

8 Nuestra solución

Para abordar la solución al problema, debemos considerar los diversos sistemas de almacenamiento disponibles. Podríamos: adquirir armarios de discos y replicar los datos entre diversas sedes dispersas geográficamente mediante software de sincronización, o contactar con un proveedor que disponga de soluciones llave en mano de tipo CAS y similares, o utilizar algún sistema de almecenamiento distribuido utilizando herramientas de software libre.

Existen diversos sistemas de almacenamiento distribuido: un disco (dispositivo de bloques) compartido, un sistema de ficheros compartido y un sistema de ficheros distribuido compartido. En nuestro caso, inicialmente estábamos interesados en investigar las posibilidades de un sistema de ficheros distribuido compartido. Nuestra pretensión era aprovechar el hecho de que el Servei de Biblioteques dispone de varias decenas de ordenadores repartidos por el campus (Opacs en Linux)⁴⁰ destinados a que los usuarios realicen consultas, para poderlos utilizar además como nodos de una red de almacenamiento distribuido. Cada nodo dispondría de un sistema de ficheros local, que mediante el software adecuado se conseguiría agregar uno a uno en un único sistema de ficheros. A su vez, a este sistema de ficheros podría accederse desde diversos hosts.

El problema, después de realizar diversas pruebas en laboratorio, fue que ningún paquete de software libre se adaptaba a nuestra situación: o bien eran proyectos que estaban en plena fase de desarrollo (y por tanto, inadecuados para producción por su inestabilidad), o bien que no estaban realmente pensados para la preservación digital y precisarían de un costoso proceso de adaptación.

Otra dificultad consistía en el gran coste de inversión que representaría apostar por alguna de las soluciones comerciales-corporativas que hemos expuesto, y el hecho de ligarse a una herramienta determinada bajo el control de un único fabricante, aspecto que consideramos que no es la mejor alternativa.

Finalmente hemos decidido rebajar nuestras pretensiones iniciales, teniendo en cuenta lo anteriormente dicho y dado que escoger una solución completa por nuestra cuenta y sin contar plenamente con el resto de la comunidad universitaria sería un esfuerzo poco constructivo a nivel práctico.

Como nuestra responsabilidad es en primer lugar profesional, pretendemos de momento, en primer lugar y como solución inmediata, imitar lo que está haciendo Internet Archive. Esto es: mantener un número determinado de copias de cada objeto, y almacenarlas en soportes físicos ubicados en diferentes sedes. La idea es adquirir dos o más sistemas de almacenamiento en disco que sean baratos (tanto en el coste de adquisición como en el de mantenimiento), y realizar las sincronizaciones entre los equipos mediante software tipo rsync.

En segundo lugar, estamos evaluando otro tipo de software, el de control de versiones, y más específicamente los distribuidos,⁴¹ porque una observación atenta revela que más allá de sus aparentes diferencias, comparten también objetivos con los nuestros, no solo el nombre (repositorios) y el método (distribuido). Este tipo es una familia de aplicaciones relativamente reciente pero que ha madurado muy rápidamente, y que en estos momentos está representada sobretodo por tres grandes nombres: Git <http://git.or.cz/>, Mercurial <http://www.selenic.com/mercurial> y Bzr <http://bazaar-vcs.org/>. Aunque probablemente el candidato más probable a ser nuestra solución escogida es Git, debido a su escalabilidad, flexibilidad, diversidad de métodos de replicación y garantías de integridad de sus datos, la decisión, en el momento de escribir estas líneas, es algo prematura, ya que hemos de confirmar que (o cual de ellos) gestionen bien grandes volúmenes de ficheros binarios. Una exposición completa y razonada de ello sería objeto de un estudio específico.

9 Anexos

Otras soluciones comerciales-corporativas:

IBM DR550 i Tivoli Storage Manager 5.3 <http://www.ibm.com>.

Iternity <http://www.iternity.com>.

Copan Systems Revolution 300A i Millennia Archive Software <http://www.copansys.com>.

Hitachi Content Archive Platform <http://www.hds.com>.

Pillar Data Systems AxiomONE File Replicator <http://www.pillardata.com/products/file-replication>.

Permabit's Permeon Compliance Vault <http://www.permabit.com>.

HP RISS <http://www.hp.com>.

Sun Honeycomb <http://www.sun.com>.

Otras iniciativas relacionadas, en software libre:

CEPH <http://ceph.sourceforge.net>.

Gluster FS <http://www.gluster.org>.

Pvfs <http://www.pvfs.org>.

Hadoop <http://lucene.apache.org/hadoop/index.html>.

Starfish Distributed FS <http://www.digitalbazaar.com>.

Flud <http://www.flud.org>.

Zumastor <http://zumastor.googlepages.com>.

Kosmos Distributed FS <http://kosmosfs.sourceforge.net>.

Cleversafe <http://cleversafe.org>.

Notes

¹ UKSG 19.2 (2006): 111-119. <http://works.bepress.com/gordon_tibbitts/1>. [Consulta: 28/02/2008].

² <http://www.archive.org/iathreads/post-view.php?id=41661>. [Consulta: 28/02/2008].

³ rsync es una herramienta con licencia GPL para sincronizar conjuntos de ficheros entre máquinas remotas, vía red, transmitiendo solamente las diferencias entre ellos. <http://www.samba.org/rsync>. [Consulta: 28/02/2008].

⁴ <http://www.archive.org/iathreads/post-view.php?id=19584>. [Consulta: 28/02/2008].

⁵ <http://webservices.xml.com/pub/a/ws/2002/01/18/brewster.html>. [Consulta: 28/02/2008].

⁶ <http://www.archive.org/iathreads/post-view.php?id=15551>. [Consulta: 28/02/2008].

⁷ <http://www.capricorn-tech.com>. [Consulta: 28/02/2008].

⁸ <http://www.capricorn-tech.com/products.php>. [Consulta: 28/02/2008].

⁹ <http://wa.archive.org/blog/2007/05/17/crawl-data-delivered-to-bibliotheque-national-de-france>. [Consulta: 28/02/2008].

¹⁰ Incluye, por ejemplo, un lenguaje de programación propio, Sawzall, que sólo tiene sentido en un sistema de miles de servidores, como los que forman parte de Google. <http://research.google.com/archive/sawzall.html>. [Consulta: 28/02/2008].

¹¹ <http://www.baselinemag.com/print_article2/0,1217,a=182664,00.asp>. [Consulta: 28/02/2008].

¹² <http://labs.google.com/papers/gfs.html>. [Consulta: 28/02/2008].

¹³ <http://research.google.com/archive/disk_failures.pdf>. [Consulta: 28/02/2008].

¹⁴ Google's Palimpsest project: promiscuous distribution of all science data sets. <http://pimm.wordpress.com/2007/09/25/googles-palimpsest-project-promiscuous-distribution-of-all-science-data-sets>. [Consulta: 28/02/2008].

¹⁵ <http://www.locks.org>. [Consulta: 28/02/2008].

¹⁶ Ibid.

¹⁷ "LOCKSS libraries are building local collections as part of an international digital preservation network. They collect and preserve in their LOCKSS boxes all genres and formats of web-based content to which they subscribe and open access titles that meet their collection criteria such as e-journals, e-books, web sites, electronic theses and dissertations, imaged collections, and government documents." <http://www.clockss.org/clocksswiki/files/LOCKSSCLOCKSSChart.pdf>. [Consulta: 28/02/2008].

¹⁸ Otra manera de comprobar cómo LOCKSS (y CLOCKSS) es una mezcla de muchos elementos dispares (robot y servor Web, analizador HTML y RTF, cliente OAI, etc) es ver la lista de productos terceros que forman parte del mismo, y que se puede ver en su página de licencia. <http://www.lockss.org/lockss/License_Information>. [Consulta: 28/02/2008].

¹⁹ <http://lockss.stanford.edu/freenix2000/freenix2000.html>. [Consulta: 28/02/2008].

²⁰ <http://www.clockss.org>. [Consulta: 28/02/2008].

²¹ <http://www.clockss.org/clocksswiki/files/LOCKSSCLOCKSSChart.pdf>. [Consulta: 28/02/2008]. La cursiva de la citació és nostra.

²² Por ejemplo, el cese de la publicación de una revista.

²³ Ibid.

²⁴ <http://daitss.fcla.edu>. [Consulta: 28/02/2008].

²⁵ <http://en.wikipedia.org/wiki/OAIS>. [Consulta: 28/02/2008].

²⁶ Network of expertise in long-term storage and long-term availability of digital resources in Germany. <http://www.langzeitarchivierung.de>. [Consulta: 28/02/2008].

²⁷ <http://kopal.langzeitarchivierung.de/index_koLibRI.php.en>. [Consulta: 28/02/2008].

²⁸ <http://www.cascommunity.org/portal/modules.php?name=Content&pa=showpage&pid=34>. [Consulta: 28/02/2008].

²⁹ <http://www.emc.com/products/systems/centera.jsp>. [Consulta: 28/02/2008].

³⁰ <http://www.emc.com/products/systems/centera.jsp>. [Consulta: 28/02/2008].

³¹ <http://www.nexsan.com/assureon.php>. [Consulta: 28/02/2008].

³² <http://www.caringo.com/products_castor.html>. [Consulta: 28/02/2008].

³³ <http://groups.google.com/group/linux.dev.kernel/msg/76ae734d543e396d>. [Consulta: 28/02/2008].

³⁴ <http://twistedstorage.sourceforge.net>. [Consulta: 28/02/2008].

³⁵ <http://twistedmatrix.com/trac/wiki/TwistedProject>[Consulta: 28/02/2008].

³⁶ <http://www.allmydata.com>. [Consulta: 28/02/2008].

³⁷ <http://allmydata.org/trac/tahoe>. [Consulta: 28/02/2008].

³⁸ <http://www.danga.com/mogilefs>. [Consulta: 28/02/2008].

³⁹ <http://www.danga.com/faq.bml>. [Consulta: 28/02/2008].

⁴⁰ Jorba, Ferran, "Els quioscs Linux a les Biblioteques UAB". En: II Jornades de Programari Lliure. Barcelona, 2003. <http://www.jornadespl.org/biblioteca/ii-jornades/ponencies/fjorba-2003.pdf>. [Consulta: 28/02/2008].

⁴¹ Auvray, Sébastien, Distributed Version Control Systems: A Not-So-Quick Guide Through, May 2008, <http://www.infoq.com/articles/dvcs-guide> [Consulta: 16/05/2008].