Hospedagem Koha: nuvem gerenciada ou servidor próprio?

O que a hospedagem Koha inclui de fato

Quando uma proposta diz “hospedagem incluída”, isso deveria cobrir sete itens. Se algum faltar, o custo simplesmente passa para a equipe interna da instituição.

• Servidor e sistema operacional: a máquina virtual, o seu dimensionamento e os patches de segurança do sistema.
• A pilha do Koha: Perl e suas dependências, MariaDB ou MySQL, o servidor web e o motor de indexação (Zebra ou Elasticsearch).
• Domínio e certificado TLS: o OPAC e a interface da equipe devem ser servidos por HTTPS, com renovação automática do certificado.
• Backups: cópia do banco de dados e dos arquivos de configuração, com retenção definida e, principalmente, com testes de restauração.
• Monitoramento: alertas de queda, de disco cheio e de processos de indexação parados.
• Atualizações: aplicação das versões de manutenção e planejamento dos saltos de versão principal.
• E-mail de saída: o Koha envia avisos de vencimento, reservas disponíveis e recuperação de senha; se o e-mail não estiver bem configurado, essa funcionalidade não existe na prática.

O e-mail de saída é o item mais subestimado. Um servidor recém-criado quase sempre cai na caixa de spam do domínio institucional até que se configurem os registros de autenticação do remetente no DNS.

Nuvem gerenciada ou servidor próprio: tabela de decisão

Nenhum dos dois modelos é melhor em abstrato. Depende de a instituição ter uma equipe de infraestrutura com capacidade real de atender mais um serviço e do rigor das suas políticas de dados.

Há um meio-termo que funciona 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 Koha fica com o fornecedor, por acesso remoto. Os dados nunca saem do perímetro institucional e a operação fica com quem conhece o sistema. É o modelo que a BiblioLabTech usa quando a TI exige que a máquina fique sob o seu controle, e é assim que funciona na Escuela Colombiana de Ingeniería Julio Garavito: catálogo Koha e repositório DSpace em um servidor dedicado da universidade, administrado pela equipe da BiblioLabTech, com HTTPS, backups automáticos e monitoramento (leia o caso).

Requisitos mínimos de servidor por tamanho do acervo

O Koha é uma aplicação Perl sobre MariaDB ou MySQL com um motor de indexação à parte; ou seja, há dois consumidores de memória para dimensionar, não um. Estes são os tamanhos que funcionam em operação real, não os mínimos absolutos de instalação:

Duas observações sobre o disco. O banco de dados de um catálogo universitário típico ocupa poucos gigabytes; o que consome espaço são os índices, os backups acumulados e os arquivos anexos, como capas e PDFs. E o disco deve ser SSD: a reindexação completa de um catálogo grande em disco mecânico pode passar de minutos para horas.

Zebra ou Elasticsearch

O Koha traz o Zebra como motor de busca padrão, e ele funciona perfeitamente para a grande maioria das bibliotecas universitárias. O Elasticsearch é a alternativa: melhora as facetas, a relevância e a busca tolerante a erros de digitação, mas eleva bastante o piso de hardware, porque é um serviço Java que convém dimensionar com pelo menos 8 GB de memória só para ele, além do que o Koha e o banco de dados já consomem.

A recomendação prática: se o acervo tem menos de 100.000 registros e ninguém reclamou da busca, fique com o Zebra. O Elasticsearch se justifica com catálogo grande, muitas consultas simultâneas ou necessidades de facetas que o Zebra não cobre. A troca de motor pode ser feita a qualquer momento, ajustando a configuração e reindexando; não é uma decisão irreversível, mas também não sai de graça.

Backups, disponibilidade e SLA

Backup que nunca foi restaurado não é backup. Estes são os parâmetros que devem ficar escritos no contrato:

• Frequência: cópia diária do banco de dados, no mínimo; em bibliotecas com circulação intensa, cópia diária mais backup incremental.
• Retenção: entre 15 e 30 dias é o razoável para uma biblioteca; além disso, o custo de armazenamento cresce sem agregar valor.
• Localização: fora do servidor de produção. Um backup guardado no mesmo disco não protege de nada.
• Teste de restauração: pelo menos uma vez por ano, documentado.
• RTO e RPO: quanto tempo o serviço pode ficar fora do ar e quantas horas de dados podem ser perdidas no pior caso. São os dois números que realmente importam.
• Disponibilidade contratada: 99,5% ao mês equivale a cerca de 3,6 horas de indisponibilidade mensal; 99,9%, a cerca de 43 minutos. Escolha o nível conforme o OPAC seja crítico na época de provas.
• Janelas de manutenção: combinadas fora do horário de aulas e avisadas com antecedência.

Domínio, TLS e acesso

O OPAC deve ficar em um subdomínio da universidade, do tipo catalogo.universidade.edu.br, e não em um domínio do fornecedor. É uma decisão de marca e de continuidade: se um dia você trocar de fornecedor, o link impresso nos guias das disciplinas e publicado no site institucional continua funcionando. Tecnicamente, basta a instituição apontar um registro DNS para o servidor.

O certificado TLS deve se renovar sozinho. A interface da equipe deve ficar em um subdomínio diferente do OPAC e, quando a política de segurança permitir, ser restrita por rede ou VPN. Se a universidade usa diretório corporativo, o Koha se integra com LDAP e Active Directory, e também com CAS, SAML e provedores OpenID Connect, o que evita manter um segundo conjunto de senhas.

Dados dos usuários e LGPD

A hospedagem também define onde ficam os dados pessoais dos usuários e o histórico de empréstimos, e muitas instituições preferem infraestrutura própria justamente por exigências sobre dados pessoais. Em qualquer modelo, o Koha permite anonimizar automaticamente o histórico de empréstimos após um prazo, configurar perfis de equipe com permissões granulares e manter registro de auditoria das operações. No Brasil, onde o tratamento de dados pessoais é regido pela Lei Geral de Proteção de Dados Pessoais (LGPD, Lei nº 13.709/2018), vale deixar no contrato de hospedagem onde os dados ficam armazenados, quem tem acesso a eles e como são devolvidos ou eliminados ao fim da relação.

O que perguntar a um fornecedor de hospedagem Koha

• Qual versão do Koha você instala e com que frequência aplica as versões de manutenção?
• O servidor é exclusivo da minha instância ou compartilhado com outras bibliotecas?
• Qual é a frequência, a retenção e a localização dos backups, e quando foi o último teste de restauração?
• Que disponibilidade mensal você garante e o que acontece se ela não for cumprida?
• Qual é o tempo de resposta para um incidente crítico, como o OPAC fora do ar, em comparação com uma solicitação comum?
• Se eu decidir sair, você me entrega o dump completo do banco de dados e os arquivos de configuração? Em que prazo e a que custo?
• O domínio e o certificado ficam em nome da instituição?
• O suporte inclui dúvidas de uso do sistema ou só incidentes de infraestrutura?

A sexta pergunta é a mais importante e a menos feita. O Koha é software livre e os dados são seus: qualquer fornecedor sério deve entregar uma cópia íntegra sem discussão. Se a resposta for ambígua, você está diante do mesmo aprisionamento que leva tantas bibliotecas a sair de um sistema proprietário, como explicamos em sistema de gestão de bibliotecas: o que é e como escolher.

Quando convém cada modelo

Escolha nuvem gerenciada se a equipe de TI não tem disponibilidade para atender mais um serviço, se a biblioteca precisa do OPAC no ar de forma contínua, se você quer custo previsível ou se vem de uma instância que nunca foi atualizada porque não havia quem a mantivesse, cenário que tratamos em como atualizar o Koha sem perder dados.

Escolha servidor próprio se a política institucional exige que os dados permaneçam no campus, se já existe infraestrutura virtualizada com backups formais e equipe que domina Linux, ou se o Koha precisa se integrar com sistemas internos que não estão expostos à internet.

Nos dois casos, o software é exatamente o mesmo, e a mudança entre modelos é viável, porque se resume a mover um banco de dados e alguns arquivos de configuração. Para planejar o projeto completo, veja também quanto custa implantar o Koha, onde a hospedagem gerenciada aparece com faixa de referência em dólares. O serviço de Koha da BiblioLabTech é cotado com e sem hospedagem, justamente porque a resposta certa depende da instituição, e todo projeto inclui o BiblioScan AI, de catalogação assistida por IA, sem custo adicional.