Hosting de DSpace: nube o servidor propio

Qué necesita DSpace para funcionar

Desde DSpace 7 la plataforma son dos aplicaciones separadas que pueden vivir en la misma máquina o en máquinas distintas, y conviene entenderlo porque cambia cómo se dimensiona el servidor.

• Backend: una aplicación Java que expone la API REST. Tradicionalmente se despliega dentro de un servidor de aplicaciones como Tomcat; desde DSpace 8 también se distribuye como un JAR ejecutable con Tomcat embebido, lo que simplifica bastante la operación. Necesita una versión moderna de Java —17 o superior en las ramas actuales— y, ojo, el backend de las versiones recientes ya no corre sobre Tomcat 9.
• Frontend: una aplicación Angular con renderizado del lado del servidor, que corre en Node y consume la API. Es la que ve el usuario final. En DSpace 10 su configuración de URL base debe coincidir exactamente con la del backend, o el renderizado en servidor y las redirecciones no funcionan.
• PostgreSQL: la base de datos con los metadatos, los usuarios, los permisos y las referencias a los archivos. Requiere la extensión pgcrypto habilitada. El soporte de Oracle quedó descontinuado: toda instalación actual va sobre PostgreSQL.
• Solr: el motor de índices, con cuatro núcleos distintos. search alimenta la búsqueda y las facetas, oai la exposición por OAI-PMH, statistics las estadísticas de uso y authority el control de autoridades. Los dos primeros se reconstruyen reindexando; los dos últimos, no: son datos que solo existen ahí.
• El assetstore: el directorio donde viven los archivos depositados. No está dentro de la base de datos y es, casi siempre, la partición que más crece.

Es una pila con más piezas que un catálogo bibliotecario. Por eso, cuando implementamos DSpace para una universidad, la conversación sobre infraestructura aparece en la primera reunión y no al final del proyecto: define plazos, costo recurrente y a quién llaman cuando algo se cae.

El almacenamiento: la diferencia que sorprende

La base de datos de un repositorio universitario típico ocupa pocos gigabytes: son metadatos. Lo que crece es el assetstore, y crece rápido, porque cada ítem trae archivos reales. Un orden de magnitud útil para presupuestar: una tesis en PDF con imágenes ronda entre 2 y 20 MB, un artículo escaneado unos pocos MB, y un dataset o un video pueden ser cientos de MB cada uno.

La consecuencia práctica es que el disco se dimensiona sobre el crecimiento anual esperado de depósitos, no sobre el catálogo actual, y se le suma el espacio de los respaldos y de los índices. En un repositorio nuevo la regla que usamos es sencilla: estimar los gigabytes del primer año, multiplicar por tres para tener margen de crecimiento y de respaldo, y exigir que el almacenamiento sea ampliable sin migrar la instancia. Quedarse sin disco en un repositorio no solo detiene los depósitos: puede detener también la indexación y dejar el buscador desactualizado sin que nadie se entere.

Respaldar solo la base de datos es el error más caro

Este es el punto que más veces hemos visto mal resuelto, incluso en instituciones con un área de tecnología sólida. En DSpace, un respaldo completo son dos respaldos: el volcado de PostgreSQL y una copia del assetstore. Respaldar solo la base de datos deja un repositorio que arranca, muestra todos los registros y no puede entregar ni un solo archivo. Respaldar solo los archivos deja una carpeta de PDF sin descripción, sin estructura y sin permisos.

Hay además un orden correcto: primero la base de datos, después los archivos. DSpace trata la base de datos como el registro autoritativo, así que es preferible terminar con un archivo en disco que la base no conoce —invisible, inofensivo— que con un registro en la base cuyo archivo no existe, que el usuario encuentra y no puede descargar. Como alternativa complementaria, DSpace puede exportar toda la jerarquía en paquetes AIP basados en METS, que incluyen metadatos y archivos en un mismo paquete; es más consistente, pero más lento y pesado, así que lo razonable es combinar ambos esquemas en frecuencias distintas.

Nube gestionada o servidor propio: tabla de decisión

Ninguno de los dos modelos es mejor en abstracto. Depende de si la institución tiene un equipo de infraestructura con capacidad real de atender un servicio más y de cuán estrictas sean sus políticas de datos.

Existe un punto intermedio que funciona muy bien en universidades con políticas de datos estrictas: el servidor es de la institución —físico o en su propia nube— y la administración de DSpace la hace el proveedor por acceso remoto. Los datos nunca salen del campus y la operación queda a cargo de quien conoce la plataforma. Es el modelo que aplicamos cuando el área de tecnología exige que la máquina esté bajo su control.

En el extremo contrario está el caso de la Universidad Americana de Paraguay, cuyo repositorio DSpace alojamos y operamos nosotros, con HTTPS, respaldos automáticos y monitoreo incluidos. Para una biblioteca sin un equipo de infraestructura dedicado, ese modelo elimina de un golpe la pregunta de quién aplica el parche del viernes.

Dominio, HTTPS y visibilidad

El repositorio debe vivir en un subdominio de la universidad —del tipo repositorio.universidad.edu— y nunca en un dominio del proveedor. No es una cuestión de marca: es que cada ítem del repositorio va a ser citado, y si el dominio cambia con el proveedor, cambian también todas las URL publicadas. Técnicamente solo requiere apuntar un registro DNS.

El certificado TLS debe renovarse solo, y hay un detalle propio de DSpace 10 que conviene verificar con el proveedor: el proxy —Apache o Nginx— debe reenviar correctamente la cabecera Host, porque el renderizado del frontend en el servidor depende de ella. Es el tipo de configuración que, mal hecha, produce un repositorio que funciona para las personas pero es invisible para los buscadores.

Ese mismo punto se extiende a la interoperabilidad: si el repositorio debe ser cosechado por los agregadores regionales, el servidor OAI-PMH tiene que estar publicado, accesible desde afuera y cumpliendo las directrices de metadatos correspondientes. Un repositorio sin OAI expuesto existe solo para quien ya conoce su dirección.

Respaldos, disponibilidad y SLA

Un respaldo que nunca se ha restaurado no es un respaldo. Estos son los parámetros que conviene dejar escritos:

• Alcance: base de datos y assetstore. Si la propuesta dice solo «respaldo diario», pregunta explícitamente si incluye los archivos.
• Frecuencia: copia diaria de la base de datos; el assetstore admite respaldo incremental, porque los archivos ya depositados no cambian.
• Retención: entre 15 y 30 días para la base de datos, y una copia mensual de más largo plazo para los archivos.
• Ubicación: fuera del servidor de producción. Un respaldo en el mismo disco no protege de nada.
• Prueba de restauración: al menos una vez al año, documentada, y restaurando ambas capas a la vez.
• RTO y RPO: cuánto puede estar caído el servicio y cuántas horas de depósitos se pueden perder en el peor caso.
• Disponibilidad comprometida: un 99,5 % mensual equivale a unas 3,6 horas de indisponibilidad al mes; un 99,9 %, a unos 43 minutos.

Para un repositorio, el RPO suele importar más que el RTO. Que el sitio esté caído dos horas es molesto; que se pierdan los depósitos de una semana de cierre de semestre es un problema de otra naturaleza.

Qué preguntarle a un proveedor de hosting de DSpace

1. ¿Qué versión de DSpace instalas y cada cuánto aplicas las versiones de mantenimiento? Con DSpace 10.0 publicado en mayo de 2026, las ramas con soporte son 8.x, 9.x y 10.x.
2. ¿El respaldo incluye el assetstore además de la base de datos, y en qué orden se toman?
3. ¿Cuánto almacenamiento incluye la cuota, cuánto cuesta ampliarlo y con qué plazo?
4. ¿El servidor es exclusivo para mi repositorio o está compartido con otras instituciones?
5. ¿Qué disponibilidad mensual comprometes y qué ocurre si no se cumple?
6. Si decido irme, ¿me entregas el volcado de PostgreSQL y el assetstore completo, en qué plazo y con qué costo?
7. ¿El dominio, el certificado y —si existe— el prefijo de handle quedan a nombre de la institución?
8. ¿El soporte incluye preguntas de uso del repositorio o solo incidentes de infraestructura?

La sexta es la más importante y la que menos se hace. DSpace es software libre y los datos son de la universidad: cualquier proveedor serio debe poder entregar una copia íntegra de ambas capas sin discusión. Y la séptima tiene una consecuencia que no siempre se ve: si el prefijo de handle queda a nombre del proveedor, cambiar de proveedor significa romper todas las citas publicadas, un problema que detallamos en cómo migrar a DSpace desde otro repositorio.

Cuándo conviene cada modelo

Elige nube gestionada si el equipo de tecnología no tiene disponibilidad para un servicio más, si nadie en la institución administra Java y PostgreSQL, si quieres un costo previsible que incluya el crecimiento del almacenamiento, o si el repositorio debe estar disponible de forma continua para la cosecha de los agregadores.

Elige servidor propio si la política institucional exige que los archivos permanezcan dentro del campus, si ya existe infraestructura virtualizada con respaldos formales y personal capacitado, o si el repositorio debe integrarse con sistemas internos que no están expuestos hacia afuera. Y considera el modelo mixto —servidor institucional, administración externa— si ambas condiciones se cruzan.

En los tres casos el software es el mismo y moverse entre modelos es viable: se reduce a trasladar una base de datos, un assetstore y unos archivos de configuración. Si además estás evaluando sumar la capa de información de investigación, el dimensionamiento cambia y conviene leer qué es DSpace-CRIS y para qué sirve; y si lo que necesitas es la cifra global del proyecto, está en cuánto cuesta implementar un repositorio DSpace. Nuestro servicio de DSpace se cotiza con hosting y sin hosting, precisamente porque la respuesta correcta depende de cada institución.