Backups, não burnout: O que lançámos no Postgresus 2.0 (e o que abandonámos)

\ Já se passaram 6 meses desde o primeiro lançamento do Postgresus. Durante este tempo, o projeto recebeu 247 commits, novas funcionalidades, bem como ~2,8 mil estrelas no GitHub e ~42 mil downloads do Docker Hub. A comunidade do projeto também cresceu, agora há 13 contribuidores e 90 pessoas no grupo do Telegram.

Neste artigo vou abordar:

• o que mudou no projeto ao longo de seis meses;
• quais novas funcionalidades surgiram
• quais são os próximos planos.

\

O que é o Postgresus?

Para aqueles que estão a ouvir falar do projeto pela primeira vez: Postgresus é uma ferramenta de backup PostgreSQL de código aberto com interface de utilizador. Executa backups programados de várias bases de dados, guarda-os localmente ou em armazenamentos externos, e notifica-o quando os backups são concluídos ou falham.

O projeto é implementado com um único comando no Docker. Pode ser instalado via script shell, comando Docker, docker-compose.yml e agora via Helm para Kubernetes. Mais sobre métodos de instalação.

Além da funcionalidade principal "fazer backups", o projeto pode:

• Armazenar backups localmente, no S3, CloudFlare R2, Google Drive, Azure Blob Storage e NAS. Mais detalhes aqui.
• Enviar notificações de estado para Slack, Discord, Telegram, MS Teams, via email e para um webhook configurável. Mais detalhes aqui.
• Separar bases de dados por espaços de trabalho, conceder acesso a outros utilizadores e guardar registos de auditoria. Mais detalhes aqui.
• Encriptar backups e credenciais. Mais detalhes aqui.
• Trabalhar tanto com bases de dados auto-hospedadas como com bases de dados geridas na nuvem.

Website - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (agradeceria uma estrela ⭐️)

A interface do projeto parece-se com isto:

Vídeo de visão geral: https://www.youtube.com/watch?v=1qsAnijJfJE

Para aqueles que querem participar no desenvolvimento, há uma página separada na documentação. Se alguém quer ajudar o projeto mas não quer programar — basta falar aos seus colegas e amigos sobre o projeto! Isto também é uma grande ajuda e contribuição para o projeto.

Eu sei como desenvolver, mas promover mesmo um projeto de código aberto é bastante difícil. O projeto ganha reconhecimento graças àqueles que fazem análises em vídeo e falam sobre o projeto nas redes sociais. Obrigado!

Novas funcionalidades que surgiram na versão 2.0

Muita coisa mudou ao longo destes seis meses. O projeto foi melhorado em quatro direções:

• funcionalidade básica expandida;
• UX melhorado;
• surgiram novas capacidades para equipas (DBAs, DevOps, equipas, empresas);
• proteção e encriptação melhoradas para atender aos requisitos empresariais.

Vamos analisar cada uma.

1) Verificação de saúde da base de dados

Além de backups, o Postgresus agora monitoriza a saúde da base de dados: mostra o tempo de atividade e alerta-o se uma base de dados estiver indisponível.

A verificação de saúde pode ser desativada e configurada.

Se a base de dados estiver indisponível — o sistema enviará uma notificação sobre isso.

2) Novas fontes para armazenar backups e enviar notificações

Inicialmente, o Postgresus só podia armazenar backups localmente e no S3. Google Drive, CloudFlare R2, Azure Blob Storage e NAS foram adicionados. Os planos incluem adicionar FTP e possivelmente SFTP e NFS.

Para notificações, inicialmente o projeto tinha Telegram e email (SMTP). Agora Slack, Discord, MS Teams e webhooks também são suportados. Além disso, os webhooks agora são configurados de forma flexível para se conectar a diferentes plataformas:

3) Gestão de espaço de trabalho e utilizador

Anteriormente, o sistema tinha apenas um utilizador (administrador), e as bases de dados eram globais para todo o sistema. Agora o Postgresus suporta a criação de espaços de trabalho para separar bases de dados e adicionar utilizadores aos espaços de trabalho. Com separação de funções:

• apenas visualização (pode ver o histórico de backup, descarregar ficheiros de backup);
• editar (pode adicionar\eliminar\modificar bases de dados além de ler).

Consequentemente, agora pode separar bases de dados:

• bases de dados do cliente X;
• bases de dados da startup Y;
• bases de dados da equipa Z;

Equipas de DBA e grandes empresas de outsourcing começaram a usar o Postgresus, por isso isto tornou-se uma funcionalidade importante. Torna o projeto útil não apenas para desenvolvedores individuais, DevOps ou DBAs, mas para equipas inteiras e empresas.

Os registos de auditoria também apareceram:

Se alguém decidir eliminar todas as bases de dados ou por alguma razão descarregar todos os backups de todas as bases de dados — isto será visível 🙃

4) Encriptação e proteção

Na primeira versão, honestamente, não tive tempo para segurança. Armazenei todos os ficheiros de backup localmente, ninguém tinha acesso a eles, e os meus projetos não eram exatamente ultra secretos.

Mas quando o Postgresus se tornou de código aberto, rapidamente aprendi que as equipas frequentemente guardam backups em buckets S3 compartilhados e não querem que outros os leiam. As senhas das bases de dados também não devem ser armazenadas na própria BD do Postgresus, já que muitas pessoas têm acesso aos seus servidores. ~~E há alguma desconfiança entre si.~~ Simplesmente não expor segredos via API já não é suficiente.

Então, a encriptação e segurança de todo o projeto tornaram-se a principal prioridade para o Postgresus. A proteção agora funciona em três níveis, e há uma página de documentação dedicada para isto.

1) Encriptação de todas as senhas e segredos

Todas as senhas de bases de dados, tokens do Slack e credenciais S3 são armazenadas encriptadas na base de dados do Postgresus. Elas são descriptografadas apenas quando necessário. A chave secreta é armazenada num ficheiro separado da BD, por isso mesmo que alguém tenha invadido a BD do Postgresus (que de qualquer forma não está exposta externamente) — eles ainda não conseguiriam ler nada. A encriptação usa AES-256-GCM.

2) Encriptação de ficheiros de backup

Os ficheiros de backup agora também são encriptados (opcionalmente, mas a encriptação está ativada por padrão). Se perdeu um ficheiro ou o guardou no S3 público — já não é tão assustador.

A encriptação usa tanto sal quanto um vetor de inicialização único. Isto impede que os atacantes encontrem padrões para adivinhar a chave de encriptação, mesmo que roubem todos os seus ficheiros de backup.

A encriptação é feita em modo de streaming, AES-256-GCM também é usado aqui.

3) Usando utilizador apenas de leitura para backups

Apesar dos dois primeiros pontos, não há método de proteção 100%. Ainda há uma pequena chance de que:

• o seu servidor seja completamente invadido, eles obtenham a chave secreta e o endereço IP legítimo para aceder à base de dados;
• um hacker de alguma forma descriptografe senhas na BD interna do Postgresus e descubra a senha da sua base de dados;
• ou, pior, não será um hacker mas alguém de dentro;
• e eles corromperão a sua base de dados, tendo previamente eliminado backups.

Então o Postgresus deve ajudar os utilizadores a minimizar os danos. A probabilidade de tal invasão pode ser próxima de zero, mas isso é um consolo frio se você for aquele a quem isso acontece.

Agora, quando adiciona um utilizador de base de dados com permissões de escrita ao Postgresus, o sistema oferece-se para criar automaticamente um utilizador apenas de leitura e executar backups através dele. As pessoas são muito mais propensas a criar uma função apenas de leitura quando isso leva um clique em vez de configurá-la manualmente na base de dados.

Aqui está como o Postgresus oferece:

Oferece muito persistentemente:

Com esta abordagem, mesmo que o seu servidor Postgresus seja invadido, tudo seja descriptografado e os atacantes ganhem acesso à sua BD — eles pelo menos não serão capazes de corromper a base de dados. Saber que nem tudo está perdido é uma consolação bastante boa.

5) Compressão por padrão, a mais otimizada

A primeira versão do Postgresus oferecia todos os algoritmos de compressão que o PostgreSQL suporta: gzip, lz4 e zstd, com níveis de compressão de 1 a 9. Honestamente, eu não entendia realmente por que alguém precisaria de todas essas opções. Eu apenas escolhi gzip com nível 5 como o que parecia um meio-termo razoável.

Mas quando o projeto se tornou de código aberto, tive que realmente pesquisar isso. Então executei 21 backups em todas as combinações possíveis e encontrei o melhor compromisso entre velocidade e tamanho.

Então agora por padrão para todos os backups zstd com nível de compressão 5 é definido, se a versão do PostgreSQL for 16 e superior. Se for inferior — ainda gzip (a propósito, obrigado novamente aos contribuidores pelo suporte ao PG 12). Aqui está o zstd 5 comparado ao gzip 5 (está na parte inferior):

Em média, os backups são comprimidos ~8 vezes em relação ao tamanho real da base de dados.

6) Suporte ao Kubernetes Helm

Este é rápido — adicionamos suporte nativo ao k8s com instalação Helm. Equipas executando k8s na nuvem agora podem implementar o Postgresus mais facilmente. Três contribuidores ajudaram com esta funcionalidade.

7) Tema escuro

Eu não sou realmente um fã de temas escuros. Mas havia muitos pedidos, então adicionei um (~~obrigado Claude pela ajuda e olho de designer~~). Surpreendentemente, acabou por ficar melhor que o tema claro e tornou-se o padrão. Eu até redesenhei o website de claro para escuro — ficou tão bom.

Antes:

Depois:

8) Livrar-se de backups incrementais e PITR (Point In Time Recovery)

Primeiro, algum contexto:

• Backup lógico — é quando o próprio PostgreSQL exporta os seus dados (para um ficheiro ou grupo de ficheiros).
• Backup físico — é quando nos conectamos ao disco rígido do PostgreSQL e fazemos uma cópia dos seus ficheiros.
• Backup incremental com suporte PITR — é um backup físico + log de alterações (WAL), copiado do disco ou via protocolo de replicação.

Eu acreditava que o Postgresus deveria eventualmente suportar backups incrementais. Afinal, é isso que ferramentas sérias fazem! Até o ChatGPT diz que ferramentas sérias podem recuperar com precisão até ao segundo e transação.

Então comecei a trabalhar nisso. Mas então a realidade bateu:

• É muito difícil torná-lo conveniente em termos de UX e DevEx. Porque você precisa ou conectar-se fisicamente ao disco com a BD, ou configurar replicação.

Para recuperação — não há opção de não se conectar ao disco com a base de dados. Para recuperar de um backup incremental, a ferramenta de backup simplesmente restaura a pasta pgdata (mais precisamente, parte dela).

Se a base de dados for realmente grande, por exemplo, vários TB e mais — é necessário ajuste fino nas configurações. Aqui a UI é mais um obstáculo do que uma ajuda.

• A maioria das nuvens (AWS, Google, Selectel) não funcionará com backups incrementais externos, se eles exigirem acesso ao disco. Em teoria, com algumas soluções alternativas, via replicação — eles funcionarão. Mas recuperar de tal backup para uma nuvem gerida ainda não funcionará de qualquer maneira.
• Todas as nuvens fornecem backups incrementais prontos para uso. Em geral, esta é uma das razões pelas quais são pagas. E mesmo elas geralmente não permitem recuperação segundo a segundo ou para um momento específico de transação. E se você não estiver na nuvem — ainda mais improvável que o seu projeto seja crítico o suficiente para exigir tal precisão.

Portanto, se o Postgresus estiver fazendo um backup de uma BD gerida — é suficiente fazê-lo aproximadamente uma vez por semana. Apenas em caso de emergência imprevista ou se a nuvem não permitir armazenar backups por tempo suficiente. Caso contrário, confie nos próprios backups incrementais da nuvem.

• Para a maioria dos projetos, backups incrementais não são realmente tão necessários. Para bases de dados pequenas, granularidade entre backups de uma hora é suficiente, se necessário com frequência. Para grandes — pelo menos uma vez por dia. Isto é suficiente para 99% dos projetos encontrarem dados perdidos ou recuperarem completamente. Estas necessidades são totalmente cobertas por backups lógicos.

Mas se você é um banco ou um desenvolvedor de BD gerida, realmente precisa da melhor configuração de backup para as suas dezenas e centenas de terabytes de dados. Aqui o Postgresus nunca superará backups físicos do WAL-G ou pgBackRest em termos de conveniência de console e eficiência para BDs com volume em TB e mais. Mas, na minha opinião, estas já são ferramentas especializadas para tais tarefas, feitas por génios e mantenedores do próprio PostgreSQL.

Na minha opinião, backups incrementais são realmente necessários em dois casos:

• No passado, quando não havia tal escolha de bases de dados geridas na nuvem e grandes projetos exigiam hospedar tudo você mesmo. Agora os mesmos bancos, marketplaces e telecom têm nuvens internas com PITR prontas para uso.
• Você é uma nuvem gerida. Mas aqui a tarefa é radicalmente mais complexa do que apenas fazer backups e recuperar deles.

Considerando tudo isso, tomei uma decisão deliberada de abandonar o desenvolvimento de backup incremental. Em vez disso, estou focado em tornar os backups lógicos tão convenientes, confiáveis e práticos para uso diário por desenvolvedores, DevOps, DBAs e empresas.

9) Muitas pequenas melhorias

Os pontos acima estão longe de ser tudo. 80% do trabalho geralmente não é visível. De cabeça, aqui está uma lista curta:

• Otimização de buffer e RAM. O Postgresus já não tenta armazenar em buffer tudo o que pg_dump envia enquanto espera que o S3 alcance (descarregar da base de dados é geralmente mais rápido do que carregar para a nuvem). O uso de RAM agora é limitado a 32 MB por backup paralelo.
• Várias melhorias de estabilidade e correções de bugs menores.
• Adicionando SMTP sem nome de utilizador e sem senha. Eu nem sabia que isso acontece...
• Adicionando tópicos para enviar notificações para grupos do Telegram.
• Documentação apareceu!
• Suporte ao PostgreSQL 12.

E muito mais.

O que não funcionou?

Claro, nem tudo funciona e algumas coisas têm que ser abandonadas. Estou a construir o Postgresus no meu tempo livre, que mal existe. Então não posso espalhar-me muito ou complicar o UX com funcionalidades desnecessárias. Muitas funcionalidades também é mau.

1) Monitorização completa de recursos da base de dados

Eu queria fazer do Postgresus uma ferramenta de monitorização PostgreSQL também. Incluindo recursos do sistema do servidor executando PostgreSQL:

• CPU
• RAM
• ROM
• Velocidade e carga de IO

Eu até fiz a base para coletar métricas (quaisquer) e um modelo para gráficos:

Acontece que o PostgreSQL só expõe o uso de RAM e métricas de IO prontas para uso.

Monitorizar outros recursos requer extensões. Mas nem toda base de dados pode instalar as extensões que preciso, então só poderia coletar métricas parciais. Então descobri que bases de dados na nuvem frequentemente não permitem instalar extensões de todo.

Então percebi que as métricas deveriam ser armazenadas em VictoriaMetrics ou pelo menos TimescaleDB, não no próprio PostgreSQL do Postgresus, o que complicaria a construção da imagem.

No final, esta funcionalidade não essencial adicionaria:

• complexidade significativa de código, significando manutenção mais difícil;
• mais requisitos de construção de imagem (componentes adicionais);
• UX complicado (como disse, muitas funcionalidades é mau);
• ~~posicionamento pouco claro: somos uma ferramenta de backup, uma ferramenta de monitorização, ou tentando fazer tudo?~~

Então abandonei a monitorização de recursos e foquei-me em fazer do Postgresus a melhor ferramenta de backup que pode ser.

2) Console SQL

Eu também queria adicionar um console SQL. Uma vez que o Postgresus já está conectado à BD, por que não executar consultas diretamente dele? Seria conveniente — sem necessidade de abrir PgAdmin, DataGrip ou DBeaver toda vez.

Nunca encontrei tempo para trabalhar nisso, apenas planeei. Um contribuidor começou na funcionalidade e fez um PR. Mas como esperado com funcionalidades complexas, muitos requisitos e casos extremos surgiram:

• necessidade de adicionar suporte à sintaxe SQL;
• adicionar autocompletar e dicas;
• fazer carregamento preguiçoso para que mesmo 100MB de linhas não venham para o navegador;
• adicionar pelo menos várias exportações para CSV e XLSX.

Isso é basicamente um projeto completo por si só, não apenas uma aba.

Decidimos abandonar a funcionalidade e poupar o esforço. Isso acabou por ser a decisão certa, já que adicionamos funções apenas de leitura que não permitem INSERT, UPDATE e DELETE de qualquer forma.

Conclusão

Essa é a jornada que o Postgresus fez em seis meses. Cresceu de um projeto de nicho para uma ferramenta de nível empresarial que ajuda tanto desenvolvedores individuais quanto equipas inteiras de DBA (fiquei surpreso ao saber disso apenas ~2 meses após o primeiro lançamento, a propósito). Estou genuinamente feliz que milhares de projetos e utilizadores confiam no Postgresus.

O projeto não está parando por aqui. O meu objetivo agora é fazer do Postgresus a ferramenta de backup PostgreSQL mais conveniente do mundo. Há um grande backlog de funcionalidades e melhorias chegando gradualmente.

As minhas principais prioridades permanecem:

• segurança do projeto — isto é crítico, sem isso todo o resto não faz sentido;
• UX conveniente em termos de usar o próprio projeto e sem excesso de funcionalidades (fazemos uma tarefa, mas muito bem);
• UX conveniente em termos de implementação: para que tudo seja implementado com um comando e nada precise ser configurado pronto para uso;
• abertura do projeto — completamente de código aberto e gratuito para qualquer pessoa ou empresa.

Se gosta do projeto ou o acha útil — eu agradeceria uma estrela no GitHub ou partilhá-lo com amigos ❤️

\