Barman The Right Mix

Barman é basicamente o que você precisa se seu banco vai pra produção

PostgreSQL é resiliente, mas ele sozinho não faz backup de forma prática. Você pode depender de pg_dump, ou tentar montar soluções com scripts shell e cron, mas quando o disco começa a encher e o WAL não para de crescer, essas gambiarras viram dor de cabeça. Barman resolve isso de um jeito que finalmente funciona sem exigir que você monitore tudo manualmente. A ferramenta é open source, escrita em Python, mantida pela EDB, e o funcionamento dela é simples no conceito mas robusto na execução. Você configura um servidor Barman separado do banco principal, e esse servidor passa a ser responsável por receber cópias dos dados, dos WALs e de tudo que é necessário para recovery. O processo todo roda via SSH, então não precisa de configuração complicada de rede além disso.

barman the right mix entre segurança e praticidade

Instalação varia conforme sua distro. No Debian ou Ubuntu, o comando direto é algo como apt-get install barman. No RHEL/CentOS/Rocky, vem do repositório EDB. Depois de instalado, o arquivo de configuração principal fica em /etc/barman.conf, e ele controla o diretório base dos backups, os usuários de serviço e parâmetros globais. Cada banco gerenciado recebe uma seção própria lá, com detalhes como host, porta, usuário de conexão e o comando de backup. O fluxo real funciona assim: você executa barman backup num servidor designado, e o Barman conecta via SSH ao PostgreSQL, pede um backup base usando pg_start_backup e pg_stop_backup, e nesse meio tempo vai coletando todos os arquivos de WAL que forem gerados. O rsync é usado para trazer esses arquivos para o diretório local do Barman. Depois, se precisar recuperar, o Barman restaura a base mais os WALs na ordem correta até o ponto desejado.

Achei um detalhe interessante que a maioria ignora: o Barman não precisa rodar na mesma máquina que o PostgreSQL, e na verdade é recomendável que rode em outra. Isso significa que se o servidor principal cair fisicamente, você ainda tem os backups em outro lugar. Configurei isso em um cliente onde o PostgreSQL ficava em nuvem AWS e o Barman em um VPS no Data Center europeu, com latência de cerca de 120ms. Funcionou perfeitamente depois de ajustar o timeout SSH e garantir que o firewall permitisse a conexão inversa do PostgreSQL pro Barman. Um problema real que tive foi com retenção. Coloquei policy de retenção de 7 dias e retenção de redundância de 2, o que significa manter dois backups completos mesmo após 7 dias. Com um banco de 500GB que crescia cerca de 20GB por dia, o espaço no servidor Barman disparou. A solução foi configurar uma política de retenção baseada em tamanho com barman option set, limitando quantos backups completos ficam armazenados, e ativar o delete --force somente quando o espaço chegava perto do limite, junto com validação automática antes de deletar qualquer coisa.

O comando barman check é um dos recursos mais subutilizados que existem. Ele roda uma série de verificações no servidor Barman e em cada banco configurado, testando conectividade SSH, permissões, espaços em disco, disponibilidade do PostgreSQL e integridade dos backups anteriores. Se algum item falhar, você fica sabendo antes de precisar recuperar, não depois. É comum ver DBAs descobrindo que o backup falhou silenciosamente há três semanas porque ninguém nunca rodou esse comando. Outro ponto que pouca gente explica bem é como o Barman trata replicação. Ele tem suporte nativo a replica slots, o que evita que o PostgreSQL descarte WALs que ainda precisam ser enviados. Isso elimina um erro clássico onde você perde WALs necessários para o recovery porque o servidor primário já os descartou. Configurei replica slots em vários ambientes e simplifica muito o gerenciamento, mas exige que o parâmetro max_slot_wal_keep_size esteja ajustado corretamente no postgresql.conf, senão você pode ter problemas de crescimento descontrolado do diretório de WAL.

A recuperação em si é onde o Barman mostra seu valor. O comando barman restore é intuitivo: você informa o ID do backup, o destino e opcionalmente o tempo ou XID até onde quer recuperar. O Barman copia os dados base, aplica os WALs na sequência certa e para no ponto escolhido. Point-in-time recovery funciona porque ele armazena cada WAL recebido, e a aplicação é sequencial e determinística. O tempo de restore depende do tamanho do backup e da velocidade do disco de destino, não do tamanho total histórico de dados. Tem limitações honestas que todo mundo deveria conhecer antes de adotar. Barman não é ideal para bancos muito pequenos, digamos abaixo de 50GB, onde pg_dump atende perfeitamente e o overhead de manter um servidor Barman separado não compensa. Também não gerencia outras bases que não sejam PostgreSQL, então se você tem MySQL ou Oracle no mesmo ambiente, precisa de outra ferramenta. A configuração inicial de SSH keys e permissões pode dar trabalho no começo, principalmente se você estiver acostumado com soluções que funcionam com um único comando mágico. E backup incremental de WAL depende dearchive_command estar corretamente configurado no PostgreSQL, senão o Barman só consegue backup completo e nada mais.

Pra quem quer começar, o download oficial fica no site do projeto Barman, que está em https://www.pgbarman.org/. Lá você encontra documentação atualizada, repositórios para instalação e exemplos práticos. Não tem custo, roda em Linux e se integra bem com ferramentas como Nagios ou Prometheus via check_barman ou exporters feitos pela comunidade. O que faz Barman valer a pena não é nenhum recurso brilhante isolado, mas a combinação de coleta automática de WAL, verificação integrada, suporte a PITR e a possibilidade de ter um servidor de backup geograficamente separado sem configurar mil scripts. Depois de resolver os primeiros problemas de configuração, ele basicamente roda sozinho e só chama sua atenção quando algo precisa ser restaurado.