O estado atual do gerenciamento de backup de código aberto para PostgreSQL

• pg_basebackup ou pg_start_backup()/pg_stop_backup
• cópia física
• arquivamento de WALs ou replicação de streaming

• pgbarman por 2ndquadrant (gratuito)
• pgbackrest (gratuito)
• pg_probackup do Postgres Professional (gratuito)
• BART por EDB (comercial)

pgbarman

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

• Arquivamento WAL
  • via rsync
  • via barman-wal-archive / put-wal
• WAL via replicação de streaming com slot de replicação
  • Assíncrono
  • Síncrono

Backup de base via pg_basebackup (backup_method =postgres)

• a maneira mais nova/moderna
• depende da tecnologia central comprovada do PostgreSQL
• recomendado pelos documentos oficiais

• sem backup incremental
• sem backup paralelo
• sem compressão de rede
• sem desduplicação de dados
• sem limite de largura de banda da rede

Backup de base via rsync (backup_method =rsync)

• antigo e comprovado
• Backup incremental
• desduplicação de dados
• compactação de rede
• backup paralelo
• limite de largura de banda da rede

• não é a forma recomendada (pelos autores)

Transferência WAL via arquivamento WAL (via rsync)

• mais simples de configurar

• Sem RPO=0 (zero perda de dados)
• não há como se recuperar de falhas de rede longas e persistentes

Transferência WAL via arquivamento WAL (via barman-wal-archive / put-wal)

• a forma mais recente e recomendada (introduzida na versão 2.6)
• mais confiável/seguro que o rsync

• Sem RPO=0 (zero perda de dados)
• ainda não há como se recuperar de falhas de rede longas e persistentes

Transferência WAL via streaming WAL com slot de replicação (via pg_receivewal)

• mais moderno (e recomendado)
• RPO=0 (zero perda de dados) no modo síncrono

• sempre associado ao slot de replicação. Pode crescer em caso de falhas de rede

• Operação remota (backups/restaurações)
• Backups incrementais. Um dos grandes recursos do barman, os backups incrementais são baseados na comparação do nível de arquivo dos arquivos do banco de dados com os do último backup do catálogo. Em barman, o termo “diferencial” refere-se a um conceito diferente:pela terminologia barman, um backup diferencial é o último backup + as alterações individuais do último backup. Os documentos do Barman dizem que fornecem backups diferenciais via WALs. Os backups incrementais do Barman funcionam no nível do arquivo, o que significa que se um arquivo for alterado, todo o arquivo será transferido. Isso é como pgbackrest e diferente de outras ofertas como pg_probackup ou BART que suportam backups incrementais/diferenciais em nível de bloco. Os backups incrementais do Barman são especificados por meio de:reuse_backup =link ou cópia. Ao definir “copiar”, conseguimos reduzir o tempo de backup, pois apenas os arquivos alterados são transferidos e copiados, mas ainda não há redução de espaço, pois os arquivos inalterados são copiados do backup anterior. Ao definir "link", os arquivos inalterados são vinculados (não copiados) do último backup. Desta forma conseguimos tanto a redução do tempo como a redução do espaço. Não quero de forma alguma trazer mais confusão nisso, mas na realidade, os backups incrementais barman são diretamente comparáveis ​​aos backups incrementais pgbackrest, já que o barman trata (via link ou cópia) um backup incremental efetivamente como um backup completo. Assim, em ambos os sistemas, um backup incremental lida com os arquivos que foram alterados desde o último backup. No entanto, em relação aos backups diferenciais, isso significa uma coisa diferente em cada um dos sistemas mencionados, como veremos a seguir.
• Faça backup do modo de espera. Barman oferece a opção de executar a maior parte das operações de backup base a partir de um modo de espera, liberando assim o primário da carga de E/S adicionada. No entanto, observe que ainda os WALs devem vir do primário. Não importa se você usa archive_command ou streaming WAL por meio de slots de replicação, você ainda não pode (até o momento em que o barman está na versão 2.6) descarregar essa tarefa para o modo de espera.
• tarefas paralelas para backup e recuperação
• Um conjunto rico e abrangente de configurações de retenção com base em:
  • Redundância (número de backups a serem mantidos)
  • Janela de recuperação (como no passado os backups devem ser mantidos)
  Na minha opinião, do ponto de vista do usuário, o acima é ótimo. O usuário pode definir reutilização_backup =link e uma janela de recuperação e deixar o barman (seu cron job) lidar com o resto. Não há backups diff/incr/full etc para se preocupar, agendar ou gerenciar. O sistema (barman) apenas faz a coisa certa de forma transparente.
• Programando seus próprios scripts de gancho pré/pós-evento.
• Remapeamento de tablespace

• A lista de discussão não é tão ativa e os mantenedores raramente escrevem ou respondem perguntas
• Nenhum recurso para retomar um backup com falha/interrompido
• Slots de replicação ou o uso de rsync/barman-wal-archive para arquivamento não perdoam em caso de falha de rede ou outras falhas do site de backup. Em ambos os casos, se a interrupção da rede for longa o suficiente e as alterações no banco de dados valerem muitos arquivos WAL, o primário sofrerá com “sem espaço no dispositivo” e eventualmente travará. (não é uma coisa boa). O que é promissor aqui é que o barman agora fornece uma maneira alternativa (para rsync) de transferir WALs para que proteção adicional contra, por exemplo, O esgotamento de espaço do pg_wal pode ser implementado no futuro, o que, juntamente com o currículo de backup, tornaria o barman perfeito, pelo menos para mim.

pgbackrest

• Um backup pode ser:
  • Completo. Um backup completo copia todo o cluster de banco de dados.
  • Diferencial (dif). Um backup diferencial copia apenas os arquivos que foram alterados desde o último backup completo. Para uma restauração bem-sucedida, o backup diferencial e o backup completo anterior devem ser válidos.
  • Incremental (incr). Um backup incremental copia apenas os arquivos que foram alterados desde o último backup (que pode ser um backup completo, diferencial ou mesmo incremental). Da mesma forma que o backup diferencial, para fazer uma restauração bem-sucedida, todos os backups anteriores necessários (incluindo este backup, o último diff e o anterior completo) devem ser válidos.
• Uma estrofe é a definição de todos os parâmetros necessários de um cluster PostgreSQL. Um servidor PostgreSQL normal tem sua própria estrofe, enquanto os servidores de backup terão uma estrofe para cada cluster PostgreSQL que eles fizerem backup.
• Uma configuração é onde as informações sobre as estrofes são mantidas (geralmente /etc/pgbackrest.conf)
• Um repositório é onde o pgbackrest mantém WALs e backups

• Backup e restauração paralelos
• Não é necessário acesso SQL direto ao servidor PostgreSQL
• Operação local/remoto
• Retenção baseada em:
  • retenção de backup completo (números de backups completos a serem mantidos)
  • retenção de backups de diferenças (números de backups de diferenças a serem mantidos)
  Os backups incrementais não têm retenção própria e expiram assim que um backup anterior expira. Assim, o usuário pode definir uma programação para fazer backups completos e um conjunto contínuo de backups de diferenças entre eles.
• Faça backup do modo de espera. Alguns arquivos ainda precisam vir do primário, mas a cópia em massa ocorre no modo de espera. Ainda assim, os WALs devem se originar do primário.
• Integridade do backup. As pessoas por trás do pgbackrest são extremamente cuidadosas quando se trata da integridade dos backups. Cada arquivo é verificado na hora do backup e também é verificado após a restauração para garantir que nenhum bug problemático de hardware ou software possa resultar em uma restauração defeituosa. Além disso, se as somas de verificação no nível da página estiverem habilitadas no cluster do PostgreSQL, elas também serão calculadas para cada arquivo. Além disso, as somas de verificação são calculadas para cada arquivo WAL.
• Se a compactação estiver desativada e os links físicos estiverem ativados, é possível exibir o cluster diretamente do catálogo. Isso é extremamente importante para bancos de dados grandes com vários TB.
• Retomada de uma volta com falha/interrupção. Muito útil no caso de redes não confiáveis.
• Restauração delta:restauração ultrarrápida para bancos de dados grandes, sem limpar todo o cluster.
• Envio de WAL assíncrono e paralelo para o servidor de backup. Este é um dos pontos mais fortes do pgbackrest. O arquivador do PostgreSQL só copia para o spool via archive-push e o trabalho pesado da transferência e do processamento acontece em um processo pgbackrest separado. Isso permite transferências massivas de WAL, garantindo tempos de resposta baixos do PostgreSQL.
• Remapeamento de tablespace
• Suporte ao Amazon S3
• Suporte para o tamanho máximo da fila WAL. Quando o site de backup está fora do ar ou a rede está falhando, o uso desta opção simulará como se o arquivamento foi bem-sucedido, permitindo que o PostgreSQL exclua o WAL evitando o preenchimento do pg_wal e, assim, salve o servidor pgsql de um possível PANIC.

• Seria realmente útil ter uma opção mais “liberal” no que diz respeito à retenção, ou seja, fornecer uma maneira de especificar declarativamente algum período de retenção e deixar o pgbackrest lidar com backups completos/diff/incr conforme necessário.
>

pg_probackup

• Suporte avançado em nível de backup que varia de:
  • Backups completos
  • Incremental de três tipos:
    • Backup de PÁGINA. Alterações de nível encontradas por meio de varredura WAL. Requer acesso total à sequência WAL ininterrupta desde o backup anterior.
    • Backup DELTA. Somente as páginas alteradas são copiadas para o backup. Independente do arquivamento WAL, coloca certa carga no servidor.
    • Backup PTRACK. Requer correção especial do núcleo pgsql. Funciona mantendo um bitmap em tempo real assim que as páginas são modificadas. Backup realmente rápido com carga mínima no servidor.
• Os backups também podem ser divididos em:
  • Backups autônomos. Esses não têm requisitos no WAL fora do backup. Sem PITR.
  • Arquivar backups. Eles dependem de arquivamento contínuo e suportam PITR.
• modelo multithread (em contraste com barman, pgbackrest e, claro, o próprio PostgreSQL que segue um modelo multiprocesso)
• Consistência de dados e validação sob demanda sem restauração
• Faça backup de um modo de espera sem acesso ao principal.
• Uma especificação de política de retenção expressiva em que a redundância pode ser usada de forma AND junto com window. A mesclagem de backups (via mesclagem) é suportada pela conversão de backups incrementais anteriores em completos como forma de liberar espaço e fornecer um método para rotação de backup suave.

• Nenhuma versão oficial oferece suporte a backups remotos. Isso significa que o pg_probackup deve ser executado no mesmo host que o cluster pgsql. (Existe uma ramificação dev que lida com backup de um site remoto, bem como arquivamento em um servidor de backup remoto)
• Não há suporte para uma retomada de backup com falha.

Controle de cluster