Pitch: Criei um script de backup simples para PostgreSQL auto hospedado (pgb2)

Eu criei o pgb2 porque eu só queria uma coisa simples: fazer backup de banco PostgreSQL rodando em VPS e enviar para um s3. Mas quando comecei a procurar ferramentas, encontrei basicamente três cenários:

1. Ferramentas muito grandes, cheias de recursos que eu não precisava.
2. Soluções pagas que custam dólares por mês.
3. Scripts soltos que funcionam, mas ficam difíceis de manter com o tempo.

Para quem está validando um MVP, criando um micro SaaS ou rodando um projeto pessoal em uma VPS barata, isso tudo é exagero. O pgb2 nasceu para resolver um problema específico, que é gerar um dump do PostgreSQL, comprimir e enviar para um storage compatível com S3.

Repositório:
https://github.com/GkIgor/pgb2
Deixar uma estrelinha, não custa nada

Objetivo do projeto

O foco não é empresa grande com cluster pesado. O meu foco está em:

1. Dev independente
2. Pequena empresa validando produto
3. Projeto auto hospedado
4. Quem quer controle total sobre o próprio backup
5. Quem não quer pagar mensalidade só para ter dump armazenado

Ele é uma CLI escrita em Go. Você configura os parâmetros do banco e do bucket, executa o comando e pode agendar via cron, sem painel web, sem daemon rodando e sem dependência externa além do próprio PostgreSQL e storage S3 compatível.

O que ele faz hoje

• Executa pg_dump
• Comprime o dump
• Envia para S3 ou serviços compatíveis como Backblaze B2 e DigitalOcean Spaces
• Permite customização via flags
• Funciona bem em ambientes simples de VPS

O que eu quero melhorar

Quero evoluir o projeto, mas mantendo o escopo claro: ferramenta simples de backup.
Algumas ideias que considero interessantes:

1. Política de retenção de backups
2. Verificação de integridade com hash
3. Comando de restore
4. Logs mais estruturados
5. Melhorias de segurança

Se começar a virar algo complexo demais, perde o sentido. Por isso, eu queria ajuda da comunidade, tem bastante criando SaaS, principalmente usando IA, o que gera muitos cases para serem aproveitados.

Como você pode contribuir

• Review de código
• Sugestões de segurança
• Issues com relatos de uso real
• Pull requests que mantenham a simplicidade
• Discussões sobre melhorias sem inflar a ferramenta

A ideia é construir algo útil para quem está começando ou rodando projetos pequenos, mas quer fazer as coisas do jeito certo.
Se você também já passou pela dor de querer um backup simples, dá uma olhada no repositório e manda feedback. Toda crítica técnica é bem-vinda.

Como surgiu?

Muito simples, na empresa que eu trabalho, um dos MVPs não rendeu, estava se pagando, mas não tinha lucro real. Portanto, surgiu uma task no meu quadro: Remover o serviço de bando de dados e auto hospedar. O custo de $20, caiu para $6. Mas ai entrou a maior preocupação. O backup!
VPS no ar, docker, portas e firewall configurado, só faltava o backup. Quando eu tirei o dump do banco, percebi que o uso de armazenamento era minusculo! Uma ferramenta parruda de backup era um desperdicio de recurso e uma dor de cabeça a mais pra mim.

Então, eu pensei "vou usar o próprio pgdump". E foi o que eu fiz. Porém, um dos requisitos do card, era fazer de forma portável. Em 30 minutos eu tinha tudo pronto, mas a portabilidade era inexistente. Então eu organizei o docker compose, gerei os certificados e documentei tudo. Quando chegou o backup, eu escrevi um shellscript e estava pronto.

Quando eu estava trabalhando como suporte, era muito comum a gente criar shellscript e compartilhar com outras pessoas. Mas era bem comum alguém modificar, fazer cagada e o suporte n2 varrer os servidores e remover tudo.

Esse relato, tocou meu coração e eu não ia deixar algo tão importante solto por ai.
Então eu abri o vscode, que estava com o código fonte do GO aberto. Ai me veio a ideia: criar um script em GO e subir o binário para o servidor. Até onde eu sei, ninguém altera binário!

E assim, surgiu o pgb2 (postgres backup B2). Ele chama o pgdump, compacta, sobe para o buket de backup e escreve no log.

Porque esse post?

Eu acabei criando um carinho por esse script, ele vai ser usado como padrão de backup da empresa. Mas ele reflete somente a realidade de um projeto. E como é o primeiro código em GO que eu faço depois de muito tempo, resolvi não deixar privado, vou compartilhar e continuar evoluindo ele sempre que for possível. Então vim divulgar, para chegar em quem precisa e em quer quer contribuir.

Construção: Como foi feito

A construção dele é bem simples, segue arvore:

.
├── build
│   └── pgb2
├── cmd
│   └── root.go
├── go.mod
├── go.sum
├── internal
│   ├── backup
│   │   ├── backup.go
│   │   ├── backup_test.go
│   │   └── test_db_timestamp.sql.gz
│   ├── compress
│   │   └── compress.go
│   ├── dump
│   │   ├── dump.go
│   │   ├── dump_test.go
│   │   └── test_db_20260213191320.sql.gz
│   ├── logutil
│   │   └── logger.go
│   ├── notify
│   ├── storage
│   │   ├── s3.go
│   │   └── s3_test.go
│   └── testutil
│       └── mock_s3.go
├── LICENSE
├── main.go
├── Makefile
└── README.md

11 directories, 19 files

Utilizamos Cobra como motor CLI, a lib da aws para S3 e Gemini para escrever os testes e revisar o código.

Plano

Atualmente, o plano é aos pouquinhos, implementar essas mudanças:

Features novas

1. Retention automática (apagar backups antigos no bucket)

   • --retention-days

2. Backup incremental

3. Criptografia opcional

   • --encrypt

4. Verificação de integridade

   • gerar SHA256 do dump
   • salvar .sha256 junto no bucket

5. Restore command

   • pgb2 restore (baixar e restaurar direto)

6. Multi-database

   • aceitar lista de bancos
   • --all-databases

7. Modo dry-run

Segurança

1. Remover ou sanitizar --dump-command
2. Validar bucket e endpoint
3. Assinar backups com hash
4. TLS obrigatório pra upload

Integrações externas

1. Notificação via webhook
2. Envio de email em caso de erro
3. Docker image oficial

Adaptar e evoluir

1. Criar config file pgb2.yaml
2. Separar core de CLI (virar lib reutilizável)