Question 1

Por que o Databasus não usa o formato de dump SQL puro para backups lógicos de PostgreSQL?

Accepted Answer

Para backups lógicos, o Databasus usa o formato custom do pg_dump com compressão zstd porque, depois de testes extensivos, é o que oferece a melhor velocidade de backup e restauração. O formato custom com compressão zstd de nível 5 dá o equilíbrio ideal entre velocidade de criação do backup, velocidade de restauração e tamanho do dump.

Question 2

Onde o Databasus é instalado?

Accepted Answer

O Databasus é instalado em /opt/databasus/

Question 3

Como funcionam os backups físicos e PITR (Point-in-Time Recovery)?

Accepted Answer

O Databasus executa backups físicos remotamente a partir do seu próprio host, conectando-se ao seu PostgreSQL pelo protocolo padrão de replicação, então nada precisa ser instalado no servidor da base de dados. Bases em redes fechadas podem ser alcançadas por um túnel SSH. Os backups físicos usam a pilha nativa do PostgreSQL 17: backups completos via pg_basebackup, incrementais em nível de bloco via pg_basebackup --incremental com base nos resumos de WAL do servidor (summarize_wal = on) e streaming contínuo de WAL via pg_receivewal. Backups físicos exigem PostgreSQL 17 ou mais recente; em versões anteriores usam-se backups lógicos com pg_dump. Para restaurar para um ponto no tempo, o pg_combinebackup reconstrói um diretório de dados utilizável a partir do backup completo e da sua cadeia de incrementais, e o PostgreSQL então reproduz o WAL até o momento alvo escolhido, recuperando para qualquer segundo entre backups. A interface do Databasus dá instruções passo a passo para restaurar num host ou numa base em Docker, seja por um script pronto que torna a restauração um único comando, seja baixando os backups e reconstruindo a cadeia de partes completas, incrementais e WAL por conta própria. Incrementais e WAL são opcionais: você pode fazer apenas um backup completo, e o WAL não é obrigatório. Usamos os backups nativos do PostgreSQL 17 porque reutilizam o mecanismo de backup já comprovado do próprio PostgreSQL em vez de reinventá-lo, funcionam com bases remotas incluindo serviços gerenciados como RDS e Cloud SQL e dão perda de dados quase nula.

Question 4

Por que o Databasus abandonou os backups baseados em agente?

Accepted Answer

Uma versão anterior do Databasus trazia um agente de backup: um binário que rodava no host da base de dados para transmitir WAL e criar backups físicos localmente. Essa primeira implementação se revelou um erro e foi removida. Era uma implementação ingênua que só copiava WAL por cima de backups completos, o que levava a um RTO longo. Era preciso configurar tanto o Databasus quanto um agente separado, quando fazer tudo remotamente de um só lugar é bem mais simples. Como o agente vivia fora do sistema principal, era difícil cobrir todos os casos de teste. Na verdade, só existe um problema que um agente resolve: alcançar uma base de dados inacessível de fora, e para 99% das pessoas isso já é resolvido executando o Databasus dentro da rede privada ou conectando por SSH, então o agente reinventava a roda e tornava um problema simples muito mais complicado do que o necessário. Ele também não podia rodar em bases gerenciadas como RDS e Cloud SQL, que proíbem instalações no host mas já expõem o protocolo de replicação, então um caminho remoto era necessário de qualquer forma. Além disso, trazia muitos casos-limite em torno de conexões quebradas, gestão de atualizações do agente e coleta de logs de um processo separado, e quanto menos partes móveis um sistema tem, mais confiável ele é no dia a dia. Os backups físicos agora rodam remotamente a partir do host do Databasus. Os backups existentes ficam seguros: ao atualizar de uma versão que ainda tem backups via agente, o Databasus não o faz em silêncio, mas avisa sobre a mudança e deixa você escolher entre ficar na versão suportada 3.42.0 ou remover os backups antigos do agente antes de atualizar. A implementação baseada em agente permanece disponível até a versão 3.42.0 e continuará funcionando por muito tempo.

Question 5

Como a IA é usada no desenvolvimento do Databasus?

Accepted Answer

A IA é usada como auxiliar para verificação da qualidade do código e busca de vulnerabilidades, limpeza e melhoria da documentação, assistência durante o desenvolvimento e dupla verificação de PRs depois da revisão humana. A IA NÃO é usada para escrever código inteiro, abordagem de vibe code, código sem verificação linha a linha ou código sem testes. O projeto tem cobertura de testes sólida, automação de pipeline de CI/CD e verificação por desenvolvedores experientes. A IA é apenas uma assistente - o trabalho é feito por desenvolvedores.

Question 6

Como fazer backup do próprio Databasus?

Accepted Answer

Para fazer backup do Databasus, vá a /opt/databasus (ou à pasta onde o instalou) e depois ao diretório databasus-data. É preciso guardar o secret.key (chave de criptografia das credenciais) e a pasta /pgdata (base de dados interna com as configurações e os metadados dos backups). Há dois cenários de recuperação: 1) Você pode recuperar os backups das bases usando apenas o secret.key, sem a interface do Databasus (veja o guia de recuperação manual); 2) Para restaurar a interface do Databasus com todas as configurações e o histórico, precisa tanto do secret.key quanto da pasta /pgdata. Para restaurar, recrie essa estrutura de pastas em outro servidor.

Question 7

Como o Databasus é apoiado pelos programas open source da Anthropic e da OpenAI?

Accepted Answer

Em março de 2026, o Databasus foi aceito tanto no Claude for Open Source da Anthropic quanto no Codex for Open Source da OpenAI. Ter o apoio desses programas é um sinal de confiabilidade — o projeto foi avaliado de forma independente e reconhecido por líderes do setor como infraestrutura open source crítica que vale a pena apoiar. Mesmo com acesso às melhores ferramentas de IA disponíveis, o Databasus mantém regras rígidas de uso de IA: nada de vibe coding, verificação humana linha a linha e cobertura de testes completa são exigidas em todas as contribuições.

Perguntas frequentes