
pgbackrest release/2.59.0
Solução de backup e restauração paralela para PostgreSQL com criptografia, restauração delta e suporte a armazenamento de objetos multi-cloud para recuperação de desastres empresariais.
pgBackRest
Backup e Restauração Confiáveis do PostgreSQL
Introdução
O pgBackRest é uma solução confiável de backup e restauração para PostgreSQL que escala de forma transparente até os maiores bancos de dados e cargas de trabalho.
O pgBackRest v2.59.1 é a versão estável atual. As notas de versão estão na página Releases.
Por favor, dê-nos uma estrela no GitHub se você gosta do pgBackRest!
Notícias
17 de agosto de 2026 - pgBackRest 2.59.1 Lançado
20 de julho de 2026 - Novo Tarball de Distribuição
20 de julho de 2026 - pgBackRest 2.59.0 Lançado
Recursos
Backup e Restauração Paralelos
A compactação normalmente é o gargalo durante as operações de backup, então o pgBackRest resolve esse problema com processamento paralelo e algoritmos de compactação mais eficientes, como lz4 e zstd.
Operação Local ou Remota
Um protocolo personalizado permite que o pgBackRest faça backup, restauração e arquivamento local ou remotamente via TLS/SSH com configuração mínima. Uma interface para consultar o PostgreSQL também é fornecida por meio da camada de protocolo, de modo que o acesso remoto ao PostgreSQL nunca é necessário, o que aumenta a segurança.
Repositórios Múltiplos
Repositórios múltiplos permitem, por exemplo, um repositório local com retenção mínima para restaurações rápidas e um repositório remoto com retenção mais longa para redundância e acesso em toda a empresa.
Backups Completos, Diferenciais e Incrementais (no Nível de Arquivo ou Bloco)
Backups completos, diferenciais e incrementais são suportados. O pgBackRest não é suscetível aos problemas de resolução de tempo do rsync, tornando os backups diferenciais e incrementais seguros sem a necessidade de calcular o checksum de cada arquivo. Backups em nível de bloco economizam espaço copiando apenas as partes dos arquivos que foram alteradas.
Rotação de Backup e Expiração do Arquivo
Políticas de retenção podem ser definidas para backups completos e diferenciais, criando cobertura para qualquer período de tempo. O arquivo WAL pode ser mantido para todos os backups ou estritamente para os backups mais recentes. Neste último caso, o WAL necessário para tornar os backups mais antigos consistentes será mantido no arquivo.
Integridade do Backup
Checksums são calculados para cada arquivo no backup e verificados novamente durante uma restauração ou verificação. Após o backup terminar de copiar os arquivos, ele aguarda até que cada segmento WAL necessário para tornar o backup consistente chegue ao repositório.
Os backups no repositório podem ser armazenados no mesmo formato de um cluster PostgreSQL padrão (incluindo tablespaces). Se a compactação estiver desabilitada e os hard links estiverem habilitados, é possível criar um snapshot de um backup no repositório e iniciar um cluster PostgreSQL diretamente no snapshot. Isso é vantajoso para bancos de dados na escala de terabytes, cuja restauração pela forma tradicional consome muito tempo.
Todas as operações utilizam fsync em nível de arquivo e diretório para garantir a durabilidade.
Checksums de Página
Se os checksums de página estiverem habilitados, o pgBackRest validará os checksums de cada arquivo copiado durante um backup. Todos os checksums de página são validados durante um backup completo, e os checksums nos arquivos que foram alterados são validados durante backups diferenciais e incrementais.
Falhas de validação não interrompem o processo de backup, mas avisos com detalhes de exatamente quais páginas falharam na validação são emitidos no console e no log de arquivo.
Esse recurso permite que a corrupção no nível de página seja detectada cedo, antes que os backups que contêm cópias válidas dos dados expirem.
Retomada de Backup
Um backup interrompido pode ser retomado do ponto em que foi interrompido. Os arquivos que já foram copiados são comparados com os checksums no manifest para garantir a integridade. Como essa operação pode ocorrer inteiramente no host do repositório, ela reduz a carga no host PostgreSQL e economiza tempo, já que o cálculo de checksum é mais rápido do que compactar e retransmitir dados.
Compactação e Checksums em Streaming
Os cálculos de compactação e checksum são realizados em streaming enquanto os arquivos são copiados para o repositório, esteja ele localizado local ou remotamente.
Se o repositório estiver em um host de repositório, a compactação é realizada no host PostgreSQL e os arquivos são transmitidos em formato compactado e simplesmente armazenados no host do repositório. Quando a compactação está desabilitada, um nível mais baixo de compactação é utilizado para fazer uso eficiente da largura de banda disponível, mantendo o custo de CPU ao mínimo.
Restauração Delta
O manifest contém checksums para cada arquivo no backup, de modo que, durante uma restauração, é possível usar esses checksums para acelerar enormemente o processamento. Em uma restauração delta, os arquivos que não estão presentes no backup são primeiro removidos e, em seguida, os checksums são gerados para os arquivos restantes. Os arquivos que correspondem ao backup são mantidos no lugar e o restante dos arquivos é restaurado como de costume. O processamento paralelo pode levar a uma redução drástica nos tempos de restauração.
Push e Get de WAL Paralelos e Assíncronos
Comandos dedicados são incluídos para enviar (push) WAL ao arquivo e obter (get) WAL do arquivo. Ambos os comandos suportam paralelismo para acelerar o processamento e são executados de forma assíncrona para fornecer o tempo de resposta mais rápido possível ao PostgreSQL.
O push de WAL detecta automaticamente segmentos WAL que são enviados várias vezes e faz a deduplicação quando o segmento é idêntico; caso contrário, um erro é gerado. O push de WAL assíncrono permite que a transferência seja descarregada para outro processo, que compacta os segmentos WAL em paralelo para obter a máxima taxa de transferência. Esse pode ser um recurso crítico para bancos de dados com volume extremamente alto de gravação.
O get de WAL assíncrono mantém uma fila local de segmentos WAL descompactados e prontos para replay. Isso reduz o tempo necessário para fornecer WAL ao PostgreSQL, o que maximiza a velocidade de replay. Conexões e armazenamento de maior latência (como S3) são os que mais se beneficiam.
Os comandos push e get garantem que o banco de dados e o repositório correspondam, comparando versões do PostgreSQL e identificadores de sistema. Isso praticamente elimina a possibilidade de configurar incorretamente o local do arquivo WAL.
Suporte a Tablespaces e Links
Tablespaces são totalmente suportados e, na restauração, os tablespaces podem ser remapeados para qualquer local. Também é possível remapear todos os tablespaces para um único local com um único comando, o que é útil para restaurações de desenvolvimento.
Links de arquivos e diretórios são suportados para qualquer arquivo ou diretório no cluster PostgreSQL. Ao restaurar, é possível restaurar todos os links para seus locais originais, remapear alguns ou todos os links, ou restaurar alguns ou todos os links como arquivos ou diretórios normais dentro do diretório do cluster.
Suporte a S3, Azure e GCS
Os repositórios do pgBackRest podem ser localizados em armazenamentos de objetos compatíveis com S3, Azure e GCS, permitindo capacidade e retenção virtualmente ilimitadas.
Criptografia
O pgBackRest pode criptografar o repositório para proteger os backups onde quer que sejam armazenados.
Proteção contra Ransomware e Malware
Quando o repositório é armazenado em armazenamento de objetos com versionamento, o pgBackRest pode ler o repositório como ele estava em um ponto no tempo. Se os backups forem excluídos ou corrompidos por acidente, malware ou ransomware, um horário alvo pode ser usado para recuperar dados de antes do dano ocorrer.
O versionamento é suportado por armazenamentos de objetos compatíveis com S3, Azure e GCS. O bloqueio de objetos (object locking) para S3 e a exclusão suave (soft delete) para GCS ou Azure podem fornecer proteção adicional contra adulteração.
Compatibilidade com dez versões do PostgreSQL
O pgBackRest inclui suporte para dez versões do PostgreSQL: as cinco versões suportadas e as últimas cinco versões EOL. Isso permite tempo suficiente para atualizar para uma versão suportada.
Primeiros Passos
O pgBackRest busca ser fácil de configurar e operar:
- Guias do usuário para vários sistemas operacionais e versões do PostgreSQL.
- Referência de comandos para operações de linha de comando.
- Referência de configuração para criar configurações do pgBackRest.
Patrocinadores
O pgBackRest não existiria sem patrocínio: novos recursos, correções de bugs, revisões de contribuições, suporte à comunidade e manutenção exigem tempo considerável. Por favor, considere um patrocínio se você usa o pgBackRest em sua empresa.
Nossos patrocinadores: AWS, Supabase, pgEdge, Tiger Data, Percona, Eon, Xata, Dalibo, Data Egret.
Somos gratos aos nossos patrocinadores por investirem em infraestrutura de código aberto que beneficia toda a comunidade PostgreSQL.
Patrocinadores anteriores: Crunchy Data, Resonate.
Contribuições
Contribuições para o pgBackRest são sempre bem-vindas! Consulte nossas Diretrizes de Contribuição para obter detalhes sobre como contribuir com recursos, melhorias ou relatos de problemas.
Suporte
O pgBackRest é totalmente gratuito e de código aberto sob a licença MIT. Você pode usá-lo para fins pessoais ou comerciais sem quaisquer restrições. Os relatos de bugs são levados muito a sério e serão tratados o mais rápido possível. Por favor, relate bugs aqui.
Criar uma política robusta de recuperação de desastres com estratégias adequadas de replicação e backup pode ser uma tarefa muito complexa e intimidante. Você pode precisar de ajuda durante a fase de arquitetura e de suporte contínuo para garantir que sua empresa continue operando sem problemas.
Nossos patrocinadores oferecem produtos e serviços que incluem suporte ao pgBackRest e podem ajudar com suas necessidades de recuperação de desastres.