Hospedagem DSpace: nuvem gerenciada ou servidor próprio para o seu repositório

O que o DSpace precisa para funcionar

Desde o DSpace 7, a plataforma é formada por duas aplicações separadas, que podem rodar na mesma máquina ou em máquinas diferentes. Entender isso muda a forma de dimensionar o servidor.

• Backend: uma aplicação Java que expõe a API REST. Tradicionalmente roda dentro de um servidor de aplicações como o Tomcat; desde o DSpace 8 também é distribuída como um JAR executável com Tomcat embutido, o que simplifica bastante a operação. As séries 8.x e 9.x exigem Java 17, o DSpace 10 exige o JDK 21, e as versões recentes já não rodam sobre o Tomcat 9.
• Frontend: uma aplicação Angular com renderização no servidor, que roda em Node.js (versão 20.19 ou superior no DSpace 10) e consome a API. É a que o usuário final vê. No DSpace 10, a URL base configurada no frontend precisa coincidir exatamente com a do backend; caso contrário, a renderização no servidor e os redirecionamentos falham.
• PostgreSQL: o banco com os metadados, os usuários, as permissões e as referências aos arquivos. O suporte ao Oracle foi descontinuado, e as versões recentes já não exigem a extensão pgcrypto, que era obrigatória no DSpace 7.
• Solr: o motor de índices, que desde o DSpace 9 precisa ser da série 9. Ele mantém vários núcleos, entre eles search (busca e facetas), oai (exposição por OAI-PMH), statistics (estatísticas de uso) e authority (controle de autoridades). Os dois primeiros se reconstroem com uma reindexação; os dois últimos, não, porque guardam dados que só existem ali.
• O assetstore: o diretório onde ficam os arquivos depositados. Ele não está dentro do banco de dados e é, quase sempre, a partição que mais cresce.

É uma pilha com mais peças do que um catálogo bibliográfico. Por isso, quando a BiblioLabTech implanta o DSpace em uma universidade, a conversa sobre infraestrutura acontece na primeira reunião, e não no fim do projeto: ela define prazos, custo recorrente e a quem ligar quando algo cair. Se você ainda está entendendo a plataforma, comece por o que é DSpace.

Armazenamento: a diferença que surpreende

O banco de dados de um repositório universitário típico ocupa poucos gigabytes, porque guarda metadados. O que cresce é o assetstore, e cresce rápido, porque cada item traz arquivos reais. Uma ordem de grandeza útil para orçar: uma tese em PDF com imagens fica entre 2 e 20 MB, um artigo digitalizado tem poucos MB, e um dataset ou um vídeo pode ter centenas de MB cada.

A consequência prática é que o disco se dimensiona pelo crescimento anual esperado de depósitos, e não pelo acervo atual, somando o espaço dos backups e dos índices. Em um repositório novo, a regra que usamos é simples: estimar os gigabytes do primeiro ano, multiplicar por três para ter margem de crescimento e de backup, e exigir que o armazenamento possa ser ampliado sem migrar a instância. Ficar sem disco não só interrompe os depósitos: pode interromper também a indexação e deixar a busca desatualizada sem que ninguém perceba.

Fazer backup só do banco de dados é o erro mais caro

É o ponto que mais vemos mal resolvido, inclusive em instituições com uma área de tecnologia sólida. No DSpace, um backup completo são dois backups: o dump do PostgreSQL e uma cópia do assetstore. Com backup só do banco, o repositório sobe, mostra todos os registros e não consegue entregar um único arquivo. Com backup só dos arquivos, sobra uma pasta de PDFs sem descrição, sem estrutura e sem permissões.

Existe ainda uma ordem correta: primeiro o banco de dados, depois os arquivos. O DSpace trata o banco como o registro de referência, então é preferível terminar com um arquivo em disco que o banco não conhece, invisível e inofensivo, do que com um registro cujo arquivo não existe, que o usuário encontra e não consegue baixar. Como complemento, o DSpace exporta toda a hierarquia em pacotes AIP baseados em METS, com metadados e arquivos no mesmo pacote. É mais consistente, mas mais lento e pesado; o razoável é combinar os dois esquemas em frequências diferentes, sem esquecer de exportar os núcleos de estatísticas e de autoridades do Solr.

Hospedagem DSpace: nuvem gerenciada ou servidor próprio

Nenhum dos dois modelos é melhor em abstrato. Tudo depende de a instituição ter uma equipe de infraestrutura com capacidade real de assumir mais um serviço e de quão rígidas são as suas políticas de dados.

Há um meio-termo que funciona muito bem em universidades com políticas de dados rígidas: o servidor é da instituição, físico ou na sua própria nuvem, e a administração do DSpace fica com o fornecedor, por acesso remoto. Os dados nunca saem do campus e a operação fica com quem conhece a plataforma. É o modelo da Escuela Colombiana de Ingeniería Julio Garavito, cujo catálogo e repositório rodam em um servidor dedicado da universidade, administrado pela BiblioLabTech, com HTTPS, backups automáticos e monitoramento.

No extremo oposto está a Universidad Americana, do Paraguai, cujo repositório DSpace a BiblioLabTech hospeda e opera na nuvem, com HTTPS, backups automáticos e monitoramento incluídos, sem servidores nem equipe de operação do lado da universidade. Para uma biblioteca sem equipe de infraestrutura dedicada, esse modelo elimina de uma vez a pergunta sobre quem aplica a correção de sexta-feira. O próprio Ibict, na sua página sobre o DSpace, lembra que a instituição precisa ter uma equipe de TI para instalar e manter o software ou contratar uma hospedagem especializada.

Domínio, HTTPS e visibilidade

O repositório deve ficar em um subdomínio da universidade, como repositorio.universidade.br, e nunca em um domínio do fornecedor. Não é questão de marca: cada item será citado, e se o domínio mudar junto com o fornecedor, mudam também todas as URLs publicadas. Tecnicamente, basta apontar um registro DNS.

O certificado TLS deve se renovar sozinho, e há um detalhe do DSpace 10 que vale conferir com o fornecedor: o proxy, seja Apache ou Nginx, precisa repassar corretamente o cabeçalho Host, porque a renderização do frontend no servidor depende dele. Mal configurado, esse ponto produz um repositório que funciona para as pessoas, mas fica invisível para os buscadores.

O mesmo vale para a interoperabilidade. Para ser coletado por agregadores, o servidor OAI-PMH precisa estar publicado, acessível de fora e cumprindo as diretrizes de metadados de cada um. No Brasil, o Oasisbr, portal do Ibict, coleta repositórios que usam OAI-PMH ou protocolo compatível e Dublin Core, e o conteúdo agregado segue para a rede LA Referencia, que por sua vez é coletada pelo OpenAIRE, e para o portal português RCAAP. Um repositório sem OAI exposto só existe para quem já conhece o seu endereço.

Backups, disponibilidade e SLA

Um backup que nunca foi restaurado não é um backup. Estes são os parâmetros que convém deixar por escrito:

• Escopo: banco de dados e assetstore. Se a proposta diz apenas "backup diário", pergunte explicitamente se ele inclui os arquivos.
• Frequência: cópia diária do banco; o assetstore admite backup incremental, porque arquivos já depositados não mudam.
• Retenção: de 15 a 30 dias para o banco e uma cópia mensal de prazo mais longo para os arquivos.
• Local: fora do servidor de produção. Um backup no mesmo disco não protege de nada.
• Teste de restauração: pelo menos uma vez por ano, documentado, restaurando as duas camadas ao mesmo tempo.
• RTO e RPO: quanto tempo o serviço pode ficar fora do ar e quantas horas de depósitos podem ser perdidas no pior caso.
• Disponibilidade: 99,5% ao mês equivalem a cerca de 3,6 horas fora do ar por mês; 99,9%, a uns 43 minutos.

Em um repositório, o RPO costuma importar mais do que o RTO. O site ficar fora do ar por duas horas incomoda; perder os depósitos de uma semana de fechamento de semestre é um problema de outra natureza.

LGPD e dados pessoais

O repositório também guarda dados pessoais: contas de depositantes, e-mails, grupos de permissão e, em um CRIS, perfis completos de pesquisadores. No Brasil, a Lei Geral de Proteção de Dados (Lei nº 13.709/2018) distingue o controlador, que é a instituição, do operador, que é o fornecedor de hospedagem. O contrato deve definir as medidas de segurança, onde ficam os dados e, se os servidores estiverem fora do país, a base legal da transferência internacional, como as cláusulas-padrão contratuais previstas na lei. Em Portugal, o mesmo papel é cumprido pelo RGPD europeu.

O que perguntar a um fornecedor de hospedagem DSpace

• Qual versão do DSpace você instala e com que frequência aplica as versões de manutenção? Com o DSpace 10.0, de maio de 2026, as séries com suporte passaram a ser 8.x, 9.x e 10.x, e o 10.1 saiu em setembro de 2026.
• O backup inclui o assetstore além do banco de dados, e em que ordem eles são feitos?
• Quanto armazenamento a mensalidade inclui, quanto custa ampliar e em que prazo?
• O servidor é exclusivo do meu repositório ou compartilhado com outras instituições?
• Que disponibilidade mensal você garante e o que acontece se ela não for cumprida?
• Se eu decidir sair, você entrega o dump do PostgreSQL e o assetstore completo, em que prazo e com que custo?
• O domínio, o certificado e, se houver, o prefixo handle ficam em nome da instituição?
• O suporte cobre dúvidas de uso do repositório ou só incidentes de infraestrutura?

A sexta pergunta é a mais importante e a menos feita. O DSpace é software livre e os dados são da universidade: qualquer fornecedor sério deve entregar uma cópia íntegra das duas camadas sem discussão. A sétima tem uma consequência que nem sempre aparece: se o prefixo handle ficar em nome do fornecedor, trocar de fornecedor significa quebrar todas as citações publicadas, um problema que detalhamos em migração e atualização do DSpace.

Quando cada modelo compensa

Escolha a nuvem gerenciada se a equipe de tecnologia não tem disponibilidade para mais um serviço, se ninguém na instituição administra Java e PostgreSQL, se você quer um custo previsível que inclua o crescimento do armazenamento ou se o repositório precisa ficar disponível de forma contínua para a coleta dos agregadores.

Escolha o servidor próprio se a política institucional exige que os arquivos permaneçam no campus, se já existe infraestrutura virtualizada com backups formais e equipe capacitada, ou se o repositório precisa se integrar a sistemas internos que não ficam expostos para fora. E considere o modelo misto, com servidor institucional e administração externa, quando as duas condições se cruzam.

Nos três casos, o software é o mesmo e mudar de modelo é viável: tudo se resume a transferir um banco de dados, um assetstore e alguns arquivos de configuração. Se você também avalia somar a camada de informação de pesquisa, o dimensionamento muda; veja o que é DSpace-CRIS. Se precisa do valor total do projeto, ele está em quanto custa um repositório DSpace. A BiblioLabTech orça o serviço de DSpace com e sem hospedagem, justamente porque a resposta certa depende de cada instituição.

O DSpace é software livre mantido pela sua comunidade internacional, com a LYRASIS como organização anfitriã, em dspace.org.