Fundamentos de Backup e Restauração

Backup e restauração é a disciplina fundamental por trás de todas as outras capacidades de recuperação do PostgreSQL, desde desfazer um único DELETE ruim até colocar um cluster de volta em operação em outra região.

Esta página constrói o modelo mental do que um backup realmente captura, como uma restauração transforma essa captura de volta em uma instância em execução, e por que o método que você escolhe define um teto rígido para o que o trabalho de recuperação posterior pode alcançar.

Resumo

• Um backup é uma representação capturada e auto-consistente do estado do cluster que um processo de restauração pode transformar de volta em uma instância PostgreSQL em execução.
• Por que Importa: Todo objetivo de recuperação posterior, de uma tabela excluída a uma região perdida, é limitado pelo que seus backups realmente capturaram e com que rapidez eles podem ser reproduzidos.
• Conceitos Chave: backup lógico, backup físico, ponto de consistência, write-ahead log (WAL), restauração, catálogo de backup.
• Quando Usar: Todo cluster de produção precisa de uma estratégia de backup implementada antes da primeira migração de esquema e antes que o primeiro byte de dados do cliente seja registrado.
• Limitações / Trade-offs: Um backup que nunca foi restaurado é apenas uma hipótese, e o método escolhido troca a velocidade de restauração pela granularidade de restauração.
• Tópicos Relacionados: recuperação point-in-time, níveis de recuperação de desastres, arquivamento de WAL, replicação de streaming.

Fundamentos

Em sua forma mais simples, um backup é uma cópia de dados tirada em um momento conhecido que uma restauração pode usar para recriar esse momento em uma instância diferente ou posterior.

O PostgreSQL suporta duas maneiras fundamentalmente diferentes de fazer essa cópia, e a distinção entre elas molda quase todas as decisões nesta seção da documentação.

Um backup lógico, produzido por pg_dump ou pg_dumpall, pede ao banco de dados em execução para descrever seus objetos e dados como instruções SQL ou um arquivo dessa intenção, para que a restauração reproduza essas instruções em uma instância PostgreSQL nova, possivelmente diferente.

Um backup físico, produzido por pg_basebackup ou uma ferramenta como pgBackRest, em vez disso, copia os arquivos de dados reais no disco, para que a restauração coloque esses arquivos de volta e deixe o próprio mecanismo de recuperação de falhas do PostgreSQL trazê-los a um estado consistente.

Como um backup físico é apenas uma cópia de arquivos que estão sendo ativamente gravados, ele precisa de uma maneira de garantir que a cópia seja internamente coerente, mesmo que arquivos diferentes tenham sido copiados em instantes ligeiramente diferentes.

Essa garantia vem do write-ahead log, o registro de todas as alterações do PostgreSQL, que a instância restaurada reproduz a partir do momento em que o backup começou até que a cópia atinja um estado consistente.

Um backup lógico contorna esse problema inteiramente, pedindo ao banco de dados para produzir um snapshot auto-consistente no nível SQL, usando o mesmo mecanismo MVCC que dá a qualquer consulta de longa duração uma visão estável dos dados.

O ponto de consistência é o momento em que um backup se torna confiável: para um dump lógico é o instante em que o snapshot foi tirado, e para um backup físico é o ponto após a reprodução do WAL atualizar a cópia do arquivo para um estado coerente.

Restauração, em ambos os casos, não é uma única ação, mas um pipeline de localizar o backup, verificá-lo, carregá-lo ou copiá-lo, e então trazer o PostgreSQL através de quaisquer etapas de recuperação que o retornem a um estado de serviço.

Um catálogo de backup é simplesmente o registro de quais backups existem, quando foram tirados e como recuperá-los, e sem um, um backup válido armazenado é indistinguível de um corrompido.

Mecânicas e Interações

Ferramentas de backup físico não precisam realmente congelar o sistema de arquivos ou parar as gravações, porque o PostgreSQL expõe uma API de baixo nível que delimita a operação de cópia e permite que o WAL preencha a lacuna.

-- Forma conceitual do que pg_basebackup e pgBackRest fazem internamente
SELECT pg_backup_start('nightly-base', fast => true);
-- ... ferramenta externa copia arquivos de dados enquanto as gravações continuam ...
SELECT pg_backup_stop(); -- retorna a posição final do WAL necessária para reproduzir

Chamar pg_backup_start não pausa o cluster; ele marca a posição do WAL onde o backup começa para que a recuperação saiba de onde a reprodução deve começar, e pg_backup_stop registra onde a reprodução deve terminar para que a cópia se torne consistente.

É por isso que um backup físico é inseparável do WAL: os arquivos sozinhos são uma mistura inconsistente de momentos diferentes, e apenas a reprodução dos segmentos de WAL gerados durante a janela de cópia os transforma em um único snapshot coerente.

Um backup lógico não tem um gap equivalente para preencher, porque pg_dump abre uma transação com um snapshot de leitura repetível e lê todos os objetos através dessa mesma visão congelada, então nada fora do dump em si precisa ser reproduzido.

Essa diferença se estende ao comportamento de restauração: restaurar um backup físico sempre reconstrói todo o cluster como ele existia no ponto de consistência, enquanto restaurar um backup lógico pode ter como alvo uma única tabela, um único esquema ou o banco de dados inteiro, porque nunca foi nada mais do que uma sequência de operações SQL independentes.

Backups também interagem com a replicação de uma forma que surpreende os novatos, porque uma réplica de streaming não é um backup, apenas uma cópia em movimento contínuo que aplica fielmente todos os erros que o primário comete, incluindo uma tabela excluída ou uma linha corrompida.

Uma réplica protege contra falha de hardware, enquanto apenas um backup independente, tirado e retido em sua própria programação, protege contra erro do operador ou corrupção lógica, e confundir os dois é uma das lacunas mais comuns em um cluster, de outra forma bem administrado.

O método de backup que você escolhe também determina o que as ferramentas de recuperação posteriores podem fazer com ele, porque a recuperação point-in-time requer um backup base físico mais um arquivo WAL contínuo, e não pode ser construída apenas a partir de um dump lógico.

Considerações Avançadas e Aplicações

Em escala, a escolha do método de backup se torna tanto uma compensação econômica e operacional quanto técnica, pesando a precisão da restauração contra o custo de armazenamento e a complexidade operacional.

Um cluster executando pgvector 0.8+ ou extensões PostGIS 3.5+ adiciona outra complicação, porque uma restauração física traz os binários e dados da extensão juntos automaticamente, enquanto uma restauração lógica requer que a instância de destino já tenha versões de extensão correspondentes instaladas antes que o dump seja carregado corretamente.

A retenção de backup é em si uma decisão arquitetônica, porque manter apenas o mínimo exigido pela política não deixa margem para corrupção descoberta lentamente, enquanto manter tudo indefinidamente transforma o custo de armazenamento em um passivo ilimitado.

Criptografia e controle de acesso pertencem ao design de backup desde o início, não como um pensamento posterior, porque um backup é funcionalmente uma cópia completa dos dados de produção em um local que é frequentemente menos examinado do que o próprio banco de dados primário.

A decisão única mais consequente em todo esse espaço é tratar backup e restauração como um fluxo de trabalho, em vez de dois, porque um caminho de restauração não testado não é um risco menor do que nenhum backup, é o mesmo risco usando um disfarce.

Mitos Comuns

• "Uma réplica é um backup." Uma réplica de streaming protege contra falha de hardware e de nó, mas replica fielmente exclusões, corrupção e migrações ruins, portanto, não pode substituir um backup retido independentemente.
• "Se o trabalho de backup foi bem-sucedido, o backup funciona." Um trabalho de backup que sai com status zero apenas prova que a cópia foi concluída, não que os dados dentro dela estão completos, não corrompidos ou restauráveis sob pressão de tempo.
• "Backups lógicos e físicos são intercambiáveis." Eles protegem contra diferentes modos de falha e suportam diferentes operações de recuperação, então a maioria dos sistemas de produção precisa de ambos em vez de escolher um.
• "Backups mais frequentes sempre significam melhor proteção." A frequência de backup apenas limita seu ponto de recuperação para esse tipo de backup, e sem arquivamento de WAL entre eles, a frequência sozinha não pode fechar pequenas lacunas de recuperação.
• "A velocidade de restauração não importa até que um incidente aconteça." A velocidade de restauração é uma função do volume de dados, hardware e ferramentas que devem ser medidos com antecedência, porque descobri-la durante uma interrupção é o pior momento possível para aprendê-la.

FAQs

Relacionados

• Noções Básicas de Backup - a receita concreta lógico vs. físico que o modelo mental desta página suporta
• pg_dump & pg_restore - detalhes de formato e paralelismo para backups lógicos
• Verificação de Backup - provando que o caminho de restauração realmente funciona
• Noções Básicas de PITR - como um backup físico mais WAL se torna uma linha do tempo que pode ser rebobinada
• Noções Básicas de DR - como a estratégia de backup alimenta os alvos de RPO e RTO

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+ e PostGIS 3.5+.