pgBackRest não é mais mantido

• Embora tenha sido projetado como uma ferramenta de backup e recuperação para PostgreSQL escalável até ambientes de grande porte, agora teve sua manutenção encerrada
• Correções de bugs, revisão de PRs, resposta a issues e desenvolvimento de novos recursos foram todos interrompidos, e optou-se por parar de forma clara em vez de manter o projeto de modo irregular
• Suporta backups full, differential e incremental, além de block-level backup, retomada de trabalhos interrompidos e delta restore, permitindo salvar e restaurar apenas as partes alteradas
• Possui uma protocol layer que abrange ambientes locais e remotos, além de multiple repositories, ampliando o escopo operacional por meio de conexões TLS/SSH e object stores compatíveis com S3, Azure e GCS
• Era uma ferramenta com ampla gama de mecanismos de garantia de integridade, como checksum, espera por WAL segments, fsync e validação de page checksum, mas daqui para frente, mesmo que surja um fork, ele precisará construir confiança 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
• Foi informado que o trabalho no projeto foi encerrado e que, daqui para frente, 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 trabalho anteriores, houve tentativa de continuar a manutenção, mas não foi possível garantir oportunidades profissionais e patrocínio suficientes para sustentar o projeto
• Considerou-se melhor encerrar de forma clara do que continuar a manutenção de maneira irregular ou incompleta
• No futuro alguém até pode fazer um fork, mas nesse caso ele será considerado um novo projeto, e o novo mantenedor terá de conquistar confiança por conta própria

Principais recursos do projeto

• Tem como objetivo 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 costuma 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, economizando espaço de armazenamento
• É possível retomar backups interrompidos, e a integridade dos arquivos já copiados é verificada novamente comparando com os checksums do manifest
• No delta restore, os arquivos que não existem no backup são removidos primeiro, e os checksums dos demais são comparados; arquivos idênticos são mantidos e só os necessários são restaurados

Operação remota e arquitetura de repositórios

• Por meio de sua própria protocol layer, é possível executar operações de backup, restore e archive tanto em ambientes locais quanto remotos, usando TLS/SSH nas conexões remotas
• A mesma protocol layer também fornece uma interface de consulta ao PostgreSQL, permitindo realizar operações sem acesso remoto direto ao PostgreSQL, o que melhora a segurança
• Suporta multiple repositories, permitindo combinar um repositório local para recuperação rápida com 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 amplia bastante a capacidade e o período de retenção
• O próprio repositório pode ser criptografado, protegendo os dados de backup onde quer que sejam armazenados

Como garante integridade e consistência

• Calcula checksum para todos os arquivos do backup e os verifica novamente durante restore ou verify
• Depois que a cópia dos arquivos termina, aguarda até que todos os WAL segments necessários cheguem ao repositório para que o backup fique em estado consistente
• Usa fsync em nível de arquivo e diretório em todas as operações para garantir durabilidade
• Se o page checksum estiver ativado no PostgreSQL, em backups full 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 checksums de página falhe, o backup não é interrompido; em vez disso, é emitido um aviso indicando quais páginas falharam, permitindo detectar cedo page-level corruption antes que um backup válido expire

Tratamento de WAL e otimização de desempenho na recuperação

• Fornece comandos dedicados de WAL push/get, ambos com suporte a processamento paralelo e execução assíncrona, para manter o tempo de resposta do PostgreSQL o mais rápido possível
• O WAL push remove duplicatas automaticamente quando o mesmo WAL segment chega várias vezes e gera erro se o conteúdo for diferente
• O WAL push assíncrono delega a transferência a outro processo, que comprime WAL segments em paralelo, sendo especialmente importante em bancos de dados com volume de escrita muito alto
• O WAL get assíncrono mantém localmente uma fila de WAL descomprimido, permitindo fornecimento imediato antes do replay, com vantagem especialmente grande em conexões de alta latência ou em armazenamentos como S3
• Tanto o WAL push quanto o get comparam a versão do PostgreSQL e o system identifier para verificar se o banco de dados e o repositório correspondem, reduzindo bastante a chance de configuração incorreta do local de archive de WAL

Flexibilidade operacional e compatibilidade

• As políticas de retenção de backup e archive expiration podem ser configuradas separadamente por full, differential e WAL, cobrindo a janela de tempo desejada
• Os backups podem ser armazenados no próprio formato 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 na escala de terabytes, onde o restore tradicional leva muito tempo
• Há suporte completo a tablespace, e no restore cada tablespace pode ser movido para outro local ou remapeado em lote para um único local
• Também há suporte a links de arquivos e diretórios, permitindo no restore manter a posição original, remapear parcial ou totalmente, ou restaurar convertendo para arquivos e diretórios comuns
• Suporta 10 versões do PostgreSQL, incluindo as 5 atualmente suportadas e as 5 mais recentes que já chegaram ao EOL, oferecendo uma boa 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 incluíram Crunchy Data e Resonate

[xguru]

Houve uma atualização relacionada a isso.

• Após anunciar a interrupção da manutenção do pgBackRest, a caixa de e-mails foi inundada
• Houve muitas mensagens de apoio
• Com a união de vários patrocinadores, o pgBackRest passará a receber financiamento, permitindo que o projeto continue
• Além disso, será contratado mais um mantenedor para distribuir a carga de trabalho e ajudar a garantir a continuidade do projeto
• A versão atual do pgBackRest está funcionando normalmente, sem bugs graves nem problemas de segurança, então não há necessidade de fazer um fork do projeto imediatamente
• Estão se esforçando ativamente para revitalizar o pgBackRest

[GN⁺]

Comentários do Hacker News

• Pelo post que o autor publicou no LinkedIn, dá para ver que o tempo e o carinho dedicados ao pgBackRest ao longo de 13 anos foram enormes, e agora ele decidiu encerrar a manutenção
  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
• Usei muito bem o pgBackRest em projetos pessoais, a ponto de até criar um guia de backup do PostgreSQL para volumes locais e armazenamento em nuvem, então acho triste que termine assim
  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
  • Hoje em dia, por causa das expectativas em torno da IA, os desenvolvedores estão sofrendo com prazos mais apertados e têm menos tempo
    Além disso, muita gente queimou dinheiro com tokens, então em alguns casos sobraram menos recursos e menos tempo ao mesmo tempo
  • Espero que projetos assim não desapareçam por continuar sem financiamento, e sinto que as dificuldades práticas do OSS são grandes demais
• Aqui não é exatamente o modelo open source em si que falhou; o que aconteceu foi que o autor não conseguiu mais encontrar apoio financeiro e por isso está mudando de rumo, o que me parece totalmente razoável
  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
  • Aprendi que, em qualquer ecossistema, se eu quero algo, preciso apoiá-lo diretamente para ajudá-lo a sobreviver
    Vale tanto para comércio local quanto para projeto open source
  • Também fico curioso se o autor considerou transformar isso em um produto pago
    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
• Acho que o que mais merece atenção aqui é a parte da aquisição da Crunchy Data
  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
  • Não desapareceu completamente e, pelo menos neste momento, os backups não vão parar
    Mas a leitura geral de que a estrutura de financiamento é frágil continua correta
  • Mas o SQLite também não está totalmente livre desse mesmo risco, então fico curioso para saber por que seria visto como mais seguro
• O código-fonte continua aí, então em vez de só lamentar, também existe a opção de fazer um fork e manter, ou pagar alguém para assumir isso
  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
  • Acho que essa postura está certa
    Todo mundo diz que está triste, mas se está mesmo, a primeira pergunta é se está triste o bastante para doar
• Pelo que vi do ecossistema, o pgBackRest era a melhor solução na área de backup para PostgreSQL
  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
• Foi bem surpreendente; eu considerava isso praticamente a ferramenta de referência para backup/restore de PG
  Fico curioso sobre como ela se compara com WAL-G e Barman
  https://github.com/wal-g/wal-g
  https://github.com/EnterpriseDB/barman
  • Não consigo fazer uma comparação precisa, mas usamos Barman há muito tempo e estamos muito satisfeitos
    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
  • Sou um dos mantenedores do wal-g e acho que, em termos de funcionalidades, ele é plenamente comparável
    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
  • Antigamente usávamos WAL-E e hoje usamos com satisfação o sucessor, WAL-G
    Quando avaliamos isso cerca de 9 anos atrás, as características de streaming PITR nos atraíram mais do que o pgBackRest
  • Entendo por que você via isso como a ferramenta principal, mas isso também me lembra algo como https://xkcd.com/2347/
• Tenho usado o pgBackRest com satisfação em um DB de produção de 2 TB e, por coincidência, estava pensando em colocá-lo esta semana também em um DB de 8 TB
  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
  • Já usei Barman em DBs de 30 TB ou mais e não tive grandes reclamações
    Para referência, sou DBRE
  • Se você está fazendo backup de Postgres de produção com vários terabytes, isso não é brincar de DBA; você já está fazendo o trabalho de verdade
  • Se sua configuração coloca os backups em armazenamento em nuvem, Barman com hook scripts provavelmente é a alternativa mais próxima
    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
  • Também fico curioso se alguém já fez backup colocando o standby sobre ZFS ou outro filesystem com suporte a snapshots
  • Eu nunca tinha usado pgBackRest, mas comecei a integrá-lo a um projeto exatamente 2 horas atrás, e quando terminei de ler todo o README ele já tinha sido atualizado
• O pgBackRest está entre as tecnologias de backup para PostgreSQL mais versáteis que existem e, pela minha experiência, outros produtos ainda não chegam nesse nível
  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
• Por enquanto, ainda dá para continuar usando normalmente
  Imagino que o autor prefira que as pessoas continuem usando até que realmente deixe de funcionar, em vez de abandonar tudo imediatamente
  • E até lá seria ótimo se alguém aparecesse como novo mantenedor
    Não sei se isso exigiria um fork ou se daria para assumir o trabalho entrando como contribuidor no repositório atual