pgBackRest
Backup e Restauração Confiável para PostgreSQL

Introdução

pgBackRest é uma solução confiável de backup e restauração para PostgreSQL que escala perfeitamente até os maiores bancos de dados e cargas de trabalho.

pgBackRest v2.59.2 é a versão estável atual. As notas de versão estão na página Releases.

Por favor, nos dê uma estrela no GitHub se você gosta do pgBackRest!

Notícias

27 de setembro de 2026 - pgBackRest 2.59.2 Lançado

17 de agosto de 2026 - pgBackRest 2.59.1 Lançado

20 de julho de 2026 - Novo Tarball de Distribuição

Recursos

Backup e Restauração em Paralelo

A compressão geralmente é o gargalo durante as operações de backup, então o pgBackRest resolve esse problema com processamento paralelo e algoritmos de compressã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 através da camada de protocolo, de modo que o acesso remoto ao PostgreSQL nunca é necessário, o que aumenta a segurança.

Múltiplos Repositórios

Múltiplos repositórios 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 Full, Diferencial e Incremental (no Nível de Arquivo ou Bloco)

Backups full, diferenciais e incrementais são suportados. O pgBackRest não é suscetível aos problemas de resolução temporal do rsync, tornando os backups diferenciais e incrementais seguros sem a necessidade de calcular checksum de cada arquivo. Backups em nível de bloco economizam espaço ao copiar apenas as partes dos arquivos que foram alteradas.

Rotação de Backup e Expiração de Arquivo

Políticas de retenção podem ser definidas para backups full e diferenciais para criar 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 um backup terminar de copiar os arquivos, ele aguarda até que cada segmento WAL necessário para tornar o backup consistente chegue ao repositório.

Backups no repositório podem ser armazenados no mesmo formato de um cluster PostgreSQL padrão (incluindo tablespaces). Se a compressão estiver desabilitada e os hard links estiverem habilitados, é possível tirar um snapshot de um backup no repositório e iniciar um cluster PostgreSQL diretamente no snapshot. Isso é vantajoso para bancos de dados em escala de terabytes que levam muito tempo para serem restaurados da maneira tradicional.

Todas as operações utilizam fsync no 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 full e os checksums em 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 enviados para o console e para o log de arquivo.

Este recurso permite que a corrupção em nível de página seja detectada precocemente, antes que os backups que contêm cópias válidas dos dados expirem.

Retomada de Backup

Um backup interrompido pode ser retomado a partir do ponto onde foi parado. Os arquivos que já foram copiados são comparados com os checksums no manifesto para garantir a integridade. Como esta operação pode ocorrer inteiramente no host do repositório, ela reduz a carga no host do PostgreSQL e economiza tempo, já que o cálculo de checksum é mais rápido do que comprimir e retransmitir dados.

Compressão e Checksums em Streaming

A compressão e os cálculos de checksum são realizados em stream enquanto os arquivos são copiados para o repositório, seja o repositório local ou remoto.

Se o repositório estiver em um host de repositório, a compressão é realizada no host do PostgreSQL e os arquivos são transmitidos em formato comprimido e simplesmente armazenados no host do repositório. Quando a compressão está desabilitada, um nível mais baixo de compressão é utilizado para fazer uso eficiente da largura de banda disponível, mantendo o custo de CPU ao mínimo.

Restauração Delta

O manifesto 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, quaisquer arquivos nã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 deixados no lugar e o restante dos arquivos é restaurado normalmente. O processamento paralelo pode levar a uma redução dramática nos tempos de restauração.

Push e Get de WAL Paralelos e Assíncronos

Comandos dedicados estão incluídos para enviar WAL para o arquivo e obter 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 os desduplica quando o segmento é idêntico, caso contrário, um erro é gerado. O push de WAL assíncrono permite que a transferência seja transferida para outro processo que comprime segmentos WAL em paralelo para máxima taxa de transferência. Este pode ser um recurso crítico para bancos de dados com volume de escrita extremamente alto.

O get de WAL assíncrono mantém uma fila local de segmentos WAL que são descomprimidos 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 com maior latência (como S3) se beneficiam mais.

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 Tablespace 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 arquivo e diretório 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 estar localizados em armazenamentos de objetos compatíveis com S3, Azure e GCS para permitir capacidade e retenção virtualmente ilimitadas.

Criptografia

O pgBackRest pode criptografar o repositório para proteger os backups onde quer que estejam armazenados.

Proteção contra Ransomware e Malware