Backup e PITR com pgBackRest

Backup full / diferencial / incremental com pgBackRest, arquivamento contínuo de WAL e recuperação para um ponto no tempo (PITR). Para servidor único, streaming replication (primary + standbys) ou cluster Patroni; o repositório pode ficar no mesmo servidor, em um servidor de backup separado (SSH) ou em object storage compatível com S3. Inclui criptografia, compressão, política de retenção, agendamento via cron/systemd e restore de teste em diretório separado; o mesmo guia também gera o runbook de restore no local para um desastre (incluindo a reconstrução do cluster Patroni a partir do backup). Diferença em relação aos similares: é a ferramenta de backup físico recomendada para produção; para backup físico e PITR sem instalar ferramentas adicionais, use o guia pg_basebackup + arquivamento de WAL; para backup lógico (dump de tabela/banco de dados, migração entre versões), use o guia pg_dump / pg_restore.

Topologia: 1 servidor, primary + standbys ou cluster Patroni; servidor de backup opcional

Cenários

• Instalação do pgBackRest + primeiro backup + restore de teste — O pgBackRest ainda não existe: software, repositório, arquivamento de WAL, primeiro backup, agendamento e um restore de teste.
• Em um desastre: restore no local (até o estado mais recente ou até um ponto no tempo) — Leve o banco de dados, no próprio servidor, a um instante presente no backup e no archive: o último instante, um horário, um xid, um LSN ou um restore point. O cluster é parado; as alterações posteriores ao alvo são perdidas.
• Há arquivos corrompidos ou excluídos no diretório de dados (reparar com delta restore) — O servidor está íntegro, mas alguns arquivos de dados não podem ser lidos ou foram excluídos: --delta grava a partir do backup apenas os arquivos diferentes e avança até o último instante do archive. O cluster é parado.
• Recuperar apenas um banco de dados (--db-include) — O cluster continua no ar: o banco de dados é restaurado em uma instância temporária (diretório e porta separados), exportado com pg_dump e carregado no servidor de produção com um novo nome. Use este cartão também para uma única tabela excluída (a partir dele, pg_dump -t).
• Restaurar o backup em outro servidor (clone / teste / relatórios) — O servidor de produção não é tocado. O backup é aberto em um novo servidor; o arquivamento de WAL é desativado para que o clone não grave no repositório de produção. Em repositório criptografado, a chave é solicitada.
• O servidor foi totalmente perdido: abrir o backup em um novo servidor e colocá-lo no lugar — Perda de disco ou servidor: o novo servidor é aberto a partir do backup e se torna o novo primary; o arquivamento de WAL e os backups continuam na mesma stanza. O servidor antigo deve permanecer desligado, sem exceção.
• Criar um novo standby a partir do backup (--type=standby) — Novo standby sem sobrecarregar o primary com a cópia: os arquivos vêm do backup, e o WAL que falta é completado a partir do archive e via streaming. O primary continua no ar.
• Os backups estão realmente íntegros? (info / check / verify e simulação de restore) — Verificações somente leitura e uma simulação de restore em diretório separado, sem tocar no servidor de produção. Também é configurado um job de verificação mensal (cron).
• Alterar o período de retenção e limpar backups antigos (expire) — Altera os parâmetros repo1-retention-full/diff, mostra primeiro com --dry-run o que será excluído e depois executa o expire. Um backup excluído não volta.

Antes de começar

• PostgreSQL … instalado e em execução (guia pg-install)…; este servidor é o primary…. Diretório de dados ….
• O cluster Patroni … está em execução (instalação do Patroni): um Leader e os demais como streaming replicas. Em todos os nodes, o diretório de dados é …, a configuração do Patroni é … e a senha da REST API está no arquivo /etc/patroni/patroni.env.
• Não há outra ferramenta de arquivamento/backup configurada (Barman, WAL-G, archive_command escrito manualmente); se houver, remova-a primeiro. Se duas ferramentas levarem o mesmo WAL para lugares diferentes, ambas ficam incompletas.… No Patroni, o valor atual está na saída de patronictl show-config.…
• O tamanho do banco de dados é conhecido. O repositório precisa de aproximadamente (número de fulls + 1) × tamanho comprimido + archive de WAL de espaço (com zst, a maioria dos bancos de dados é comprimida para 1/3–1/5).
• O diretório do repositório … está em um disco/compartilhamento NFS separado do banco de dados e montado de forma permanente (fstab).
• No servidor de backup há um disco separado montado, com espaço suficiente para …. O servidor de backup é da mesma família de sistema operacional que o banco de dados.
• Os servidores resolvem os nomes uns dos outros (…, …) e a porta 22/tcp (SSH) está liberada entre eles.
• Os standbys (………, ……) são streaming standbys que recebem WAL do primary e usam o mesmo caminho de PGDATA que o primary (…).
• O bucket … foi criado; há uma chave de acesso (access key + secret key) com permissão de leitura/escrita/exclusão apenas neste bucket. O bucket não tem regra de lifecycle que exclua objetos (a retenção é gerenciada pelo pgBackRest). O servidor consegue acessar o endpoint.
• Relógio sincronizado (NTP). O horário alvo do PITR e as assinaturas S3 dependem do horário correto.
• Os servidores têm acesso aos repositórios PGDG e EPEL (ou a um mirror interno); a dependência libssh2 do pgBackRest vem do EPEL.
• O local onde a chave de criptografia será guardada (cofre de senhas / vault) está pronto. Se a chave não for guardada fora do servidor, os backups não poderão ser abertos em caso de perda do servidor.

Fases do guia

• Instalação do software pgBackRest — Adicionar o repositório PGDG (servidor de backup) · Adicionar o repositório PGDG (servidor de backup) · Habilitar o repositório EPEL · Instalar o pgBackRest · Criar o usuário pgbackrest · Remover o arquivo de configuração antigo
• Preparação do repositório — Criar o diretório do repositório · Criar o diretório do repositório · Gerar a chave SSH (servidor de backup) · Gerar a chave SSH (servidores de banco de dados) · Autorizar a chave do servidor de backup · Autorizar as chaves dos servidores de banco de dados …
• Configuração do pgBackRest — Gravar o arquivo de configuração · Gravar o arquivo de configuração (servidor de backup) · Gravar o arquivo de configuração (servidores de banco de dados) · Informar as chaves de acesso S3 · Gerar a chave de criptografia · Gravar a chave de criptografia no servidor … …
• Stanza e primeiro backup — Criar a stanza · Criar a stanza · Validar a configuração (check) · Fazer o primeiro backup full · Fazer o primeiro backup full · Ver o estado do repositório (info) …
• Agendamento do backup — Verificar o caminho do comando pgbackrest · Gravar o script de backup · Ajustar o dono e a permissão do script · Criar o service e os timers do systemd · Testar o agendamento (disparo manual) · Preparar o serviço cron …
• Verificação e teste de recuperação — Verificar se o arquivamento de WAL está funcionando · Gravar dados de teste e registrar o horário alvo · Preparar o diretório do restore de teste · Restaurar em diretório separado até o horário alvo · Iniciar o cluster de teste em porta separada · Verificar os dados recuperados …
• Monitoramento e manutenção — Verificar a integridade do repositório (verify) · Verificar a integridade do repositório (verify) · Monitorar a idade do último backup · Monitorar a idade do último backup · Segunda cópia e guarda das chaves
• Diagnóstico: arquivo corrompido ou ausente? — Encontrar o erro no log e o arquivo afetado · Identificar o objeto corrompido · Confirmar que há um backup e um archive íntegros
• Verificação antes do restore — Listar os backups · Verificar as conexões das aplicações · Parar os standbys · Parar o PostgreSQL · Copiar o diretório de dados atual (se houver espaço)
• Restore no local — Restaurar (--delta) · Iniciar o PostgreSQL e aguardar o fim do recovery · Verificar os dados no alvo (pause) · Concluir o recovery e fazer o promote
• Verificação — Limpar as configurações de restore · Verificar o estado do cluster · Verificar os dados da aplicação · Confirmar que a corrupção foi eliminada (amcheck) · Confirmar que o arquivamento continua · Fazer um novo backup full …
• Antes do restore: parar o cluster Patroni — Listar os backups · Registrar o estado do cluster e a configuração dinâmica · Parar as aplicações · Parar o Patroni nas réplicas · Parar o Patroni no leader · Copiar o diretório de dados atual (se houver espaço)
• Verificação e limpeza (Patroni) — Confirmar que o arquivamento continua · Fazer um novo backup full · Verificar o cluster e o acesso das aplicações · Excluir os diretórios de dados postos de lado
• Patroni: recriar o node corrompido (reinit) — Descobrir em qual node está a corrupção · Se o node corrompido for o leader, transferir a liderança · Recriar a réplica corrompida (reinit)
• Verificação de backup e simulação de restore — Estado dos backups e idade do último backup (info) · Confirmar que o arquivamento está funcionando agora (check) · Verificar a integridade do repositório (verify) · Preparar o diretório da simulação · Restaurar o último backup no diretório da simulação · Iniciar a instância da simulação e aguardar o recovery …
• Agendamento da verificação mensal — Gravar o script de verificação mensal · Ajustar a permissão do script e testá-lo com o ambiente do cron · Gravar a tarefa mensal do cron · Ajustar as permissões do arquivo do cron
• Alterar a política de retenção — Configuração de retenção atual e backups · Alterar a configuração de retenção · Mostrar o que será excluído (dry-run) · Excluir os backups antigos (expire) · Verificar a ocupação do repositório e o agendamento