pgbackrest/pgbackrest
(github.com/pgbackrest)- Uma ferramenta de backup e recuperação para PostgreSQL, projetada para escalar até ambientes de grande porte, mas que agora está em estado de fim de manutenção
- Correções de bugs, revisão de PRs, resposta a issues e desenvolvimento de novos recursos foram todos interrompidos, e optou-se por encerrar claramente o projeto em vez de mantê-lo de forma irregular
- Suporta backups full, differential e incremental, além de block-level backup, retomada de operações interrompidas e delta restore, permitindo salvar e restaurar apenas as partes alteradas
- Conta com uma protocol layer para ambientes locais e remotos e multiple repositories, ampliando o escopo operacional por meio de conexões TLS e SSH e object stores compatíveis com S3, Azure e GCS
- Era uma ferramenta com ampla cobertura de mecanismos de garantia de integridade, como checksum, espera por segmentos WAL, fsync e verificação de page checksum, mas daqui para frente qualquer fork precisará construir sua própria credibilidade separadamente
Fim da manutenção e estado do projeto
- pgBackRest é uma ferramenta de backup e recuperação para PostgreSQL, mas atualmente não é mais mantida
- O trabalho no projeto foi interrompido, e foi declarado que não será mais dedicado tempo a correções de bugs, revisão de PRs, resposta a issues ou desenvolvimento de novos recursos
- Mesmo após o fim do patrocínio e do vínculo de contratação anteriores, houve tentativa de continuar a manutenção, mas não foi possível garantir oportunidades de trabalho e patrocínio suficientes para sustentar o projeto
- Em vez de seguir com uma manutenção irregular ou incompleta, considerou-se melhor encerrar de forma clara
- No futuro, alguém até pode fazer um fork, mas nesse caso ele será tratado como um novo projeto, e o novo mantenedor terá de construir confiança separadamente
Principais recursos do projeto
- O objetivo era backup e recuperação escaláveis até ambientes PostgreSQL de grande porte, e a versão estável atual é a v2.58.0
- Foi projetado para reduzir o custo de compressão, que tende a ser um gargalo em backups, usando processamento paralelo e métodos de compressão como lz4 e zstd
- Suporta backups full, differential e incremental e, além do nível de arquivo, também usa block-level backup para copiar apenas as partes alteradas e economizar espaço de armazenamento
- É possível retomar backups interrompidos, e a integridade dos arquivos já copiados é verificada novamente por comparação com os checksums do manifest
- No delta restore, os arquivos que não existem no backup são removidos primeiro, depois os checksums dos arquivos restantes são comparados, mantendo intactos os que coincidem e restaurando apenas os necessários
Operação remota e arquitetura de repositórios
- Por meio de sua própria protocol layer, é possível executar backup, restauração e arquivamento tanto em ambientes locais quanto remotos, usando TLS/SSH para conexões remotas
- A mesma protocol layer também fornece uma interface de consulta ao PostgreSQL, permitindo operar sem acesso remoto direto ao PostgreSQL e aumentando a segurança
- Suporta multiple repositories, permitindo usar ao mesmo tempo um repositório local para recuperação rápida e um repositório remoto para retenção de longo prazo e redundância
- Os repositórios também podem ficar em object stores compatíveis com S3, Azure e GCS, o que permite ampliar bastante a capacidade e o período de retenção
- O próprio repositório pode ser criptografado, protegendo os dados de backup independentemente de onde estejam armazenados
Como garante integridade e consistência
- Calcula checksums para todos os arquivos do backup e os verifica novamente durante restore ou verify
- Após o término da cópia dos arquivos, aguarda até que todos os segmentos WAL necessários cheguem ao repositório para garantir que o backup fique em um estado consistente
- Usa fsync no nível de arquivos e diretórios em todas as operações para garantir durabilidade
- Se o page checksum estiver ativado no PostgreSQL, em backups full ele valida os checksums de página de todos os arquivos, e em backups differential e incremental valida apenas os arquivos alterados
- Mesmo que a validação de page checksum falhe, o backup não é interrompido; em vez disso, um aviso informa quais páginas falharam, permitindo detectar cedo page-level corruption antes que um backup válido expire
Processamento de WAL e otimização do desempenho de recuperação
- Fornece comandos dedicados para WAL push/get, ambos com suporte a processamento paralelo e execução assíncrona, projetados para manter o tempo de resposta do PostgreSQL o mais rápido possível
- O WAL push elimina duplicatas automaticamente quando o mesmo segmento WAL chega várias vezes, e gera erro se o conteúdo for diferente
- O WAL push assíncrono delega a transmissão a outro processo e comprime segmentos WAL em paralelo, o que é especialmente importante em bancos de dados com volume de escrita muito alto
- O WAL get assíncrono mantém localmente uma fila de WAL descompactado, permitindo fornecimento imediato antes do replay, o que traz benefícios maiores em conexões de alta latência ou em armazenamentos como S3
- Tanto no WAL push quanto no get, a versão do PostgreSQL e o system identifier são comparados para confirmar que o banco de dados e o repositório correspondem, reduzindo bastante a chance de configurar incorretamente o local de archive de WAL
Flexibilidade operacional e compatibilidade
- As políticas de backup retention e archive expiration podem ser configuradas separadamente por full, differential e WAL, cobrindo o intervalo de tempo desejado
- Os backups podem ser armazenados no formato nativo de cluster do PostgreSQL e, se a compressão for desativada e hard link for habilitado, também é possível iniciar diretamente um cluster PostgreSQL sobre um snapshot do repositório
- Essa abordagem é vantajosa em bancos de dados em escala de terabytes, nos quais o restore tradicional leva muito tempo
- Há suporte completo a tablespace, e durante o restore cada tablespace pode ser movido para um local diferente ou remapeado em lote para um único local
- Também há suporte a links de arquivos e diretórios, permitindo no restore manter o local original, fazer remapeamento parcial ou total, ou converter e restaurar como arquivos e diretórios normais
- Suporta 10 versões do PostgreSQL, incluindo as 5 versões atualmente suportadas e as 5 versões recentes já em EOL, para oferecer bastante margem de tempo para upgrades
Recursos de referência e estado do patrocínio
- User guides
- Command reference
- Configuration reference
- O patrocinador atual é a Supabase
- Patrocinadores anteriores incluem Crunchy Data e Resonate
1 comentários
Comentários do Hacker News
Houve patrocínio corporativo, mas ele também vinha colocando noites e fins de semana nisso; depois da venda da Crunchy Data, continuou mantendo o projeto enquanto tentava encontrar uma posição para seguir com esse trabalho, mas isso não deu certo
Para garantir o sustento, ele precisa buscar oportunidades mais amplas e, com isso, não consegue mais dedicar o tempo necessário para manutenção, correção de bugs, revisão de PRs e resposta a issues, então pretende arquivar o repositório
O guia está em https://github.com/freakynit/postgre-backup-and-restore-guide, e sou realmente grato por todo o tempo e esforço investidos até aqui
Além disso, muita gente queimou dinheiro com tokens, então em alguns casos sobraram menos recursos e menos tempo ao mesmo tempo
Se isso era uma ferramenta de nível de produto que entrega valor real em ambientes comerciais, indo além de um projeto de hobby, então certamente existe espaço para uma empresa com fins lucrativos preencher essa lacuna
Mas os usuários precisam virar clientes e pagar de fato; não é sustentável continuar enviando relatórios de bug e reclamações para mantenedores gratuitos
Precisamos de uma nova solução para a sustentabilidade financeira do FOSS, porque só doações parecem insuficientes
Vale tanto para comércio local quanto para projeto open source
Só que cada contribuidor pode ter direitos autorais sobre partes do código, então, dependendo de haver ACL e da jurisdição, talvez fosse preciso organizar esses direitos e até chegar a acordos sobre divisão de receita
Enquanto havia patrocínio corporativo, tudo funcionava, mas a empresa foi vendida, o novo dono mudou as prioridades e uma ferramenta de infraestrutura com 3.8k stars ficou imediatamente instável; os usuários nem sabiam que a fonte de financiamento da ferramenta de backup deles dependia da estratégia de M&A de terceiros
Por isso eu também estou migrando aos poucos para arquivos rastreados com SQLite e git
Afinal, até stacks de Postgres gerenciados acabam apoiados em várias ferramentas mantidas por pessoas cuja situação financeira ninguém conhece
Mas a leitura geral de que a estrutura de financiamento é frágil continua correta
Aproveitando, talvez faça sentido revisar agora mesmo os projetos dos quais você depende e não quer perder, e já configurar apoio financeiro imediatamente
Todo mundo diz que está triste, mas se está mesmo, a primeira pergunta é se está triste o bastante para doar
Especialmente porque não tratava só de backup, mas também de restauração e verificação de forma realmente séria, o que é raro; e eu já sofri bastante no trabalho por negligenciar isso
Os detalhes estão em https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
Então isso parece uma perda bem grande
Fico curioso sobre como ela se compara com WAL-G e Barman
https://github.com/wal-g/wal-g
https://github.com/EnterpriseDB/barman
Toda noite criamos um DB nightly restaurado com Barman e também o usamos para treinamento de usuários/testes, verificando continuamente se o backup de fato está íntegro, e há anos isso funciona sem problemas
Depois de alguns anos de inatividade, voltei a trabalhar com managed Postgres, e espero que além do delta backup que o wal-g oferece com comparação própria de blocos, ele também passe a suportar pg17 incremental backup
E realmente vale a pena usar o daemon mode
É uma pena ver uma ferramenta concorrente desaparecer, mas ainda há muito espaço para melhorar nessa área, e quando o Postgres quer rodar em um sistema sem overcommit, C pode ter vantagens sobre Golang
Quando avaliamos isso cerca de 9 anos atrás, as características de streaming PITR nos atraíram mais do que o pgBackRest
Então agora fico na dúvida se a alternativa mais próxima seria wal-g, barman ou databasus
Eu disse que só estava brincando de DBA, mas na prática essa escolha é bem importante
Para referência, sou DBRE
A documentação relacionada está em https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
https://github.com/aiven-open/pghoard também parece bom, mas ainda não testei pessoalmente
Por isso é ainda mais triste ver isso acontecer, e não deve ser fácil alcançar paridade funcional com essa ferramenta excelente
Se possível, espero que seja uma decisão reversível; se não, também gostaria que o projeto PostgreSQL considerasse absorvê-lo no contrib
Imagino que o autor prefira que as pessoas continuem usando até que realmente deixe de funcionar, em vez de abandonar tudo imediatamente
Não sei se isso exigiria um fork ou se daria para assumir o trabalho entrando como contribuidor no repositório atual