Questão de Banco de Dados — PostgreSQL — FCC 2026

PostgreSQL: backup físico, WAL e point-in-time recovery

Gabarito: letra B. A estratégia mais adequada combina backup físico completo com pg_basebackup em servidor de replicação assíncrona e arquivamento contínuo do WAL (Write-Ahead Log), o que permite a recuperação pontual (point-in-time recovery). Essa é a prática recomendada pela documentação oficial do PostgreSQL para garantir alta disponibilidade e integridade dos dados.

O PostgreSQL é um SGBD objeto-relacional de código aberto, amplamente utilizado por sua robustez e conformidade com padrões. Para garantir a disponibilidade e a recuperação de dados, o administrador precisa entender dois conceitos fundamentais: o WAL e os tipos de backup.

O WAL (Write-Ahead Log) é o mecanismo de log de transações do PostgreSQL. Antes de qualquer alteração ser gravada nos arquivos de dados, ela é registrada no WAL. Isso garante a durabilidade das transações (propriedade ACID) e permite a recuperação do banco em caso de falha. O WAL é essencial para a recuperação pontual: ao restaurar um backup físico e aplicar os arquivos WAL arquivados, é possível reconstruir o banco até um instante específico no tempo, minimizando a perda de dados.

Existem dois tipos principais de backup no PostgreSQL:

• Backup físico (nível de arquivo): copia os arquivos de dados do cluster, incluindo o WAL. É a base para a recuperação pontual e para a configuração de replicação. A ferramenta pg_basebackup é a forma recomendada de realizar esse tipo de backup, pois produz uma cópia consistente do cluster.

• Backup lógico (nível de banco): exporta os dados em formato SQL ou outro formato legível, usando ferramentas como pg_dump e pg_dumpall. É útil para migrações, backups de tabelas específicas ou bancos pequenos, mas não captura o estado completo do cluster (como roles, tablespaces e o WAL) e não é adequado para recuperação pontual em larga escala.

A replicação é outra técnica de alta disponibilidade. No PostgreSQL, a replicação pode ser síncrona ou assíncrona. Na replicação síncrona, o servidor primário aguarda a confirmação do servidor standby antes de confirmar a transação, garantindo zero perda de dados, mas com impacto no desempenho. Na assíncrona, o primário não aguarda, o que melhora o desempenho, mas pode haver perda de dados em caso de falha. A replicação não substitui o backup: ela protege contra falhas de hardware do servidor primário, mas não contra erros lógicos (como um DELETE sem WHERE) ou corrupção de dados propagada para o standby.

A manutenção de desempenho também é crucial. O comando VACUUM é usado para limpar versões antigas de linhas (devido ao MVCC) e atualizar estatísticas. O VACUUM FULL reescreve a tabela para eliminar a fragmentação, mas bloqueia a tabela durante a operação, causando indisponibilidade. Por isso, não deve ser executado diariamente em tabelas grandes; o VACUUM comum (sem FULL) é suficiente para a manutenção rotineira, e o VACUUM FULL deve ser usado com moderação, em janelas de manutenção.

A banca explora a confusão entre backup físico e lógico, entre replicação e backup, e entre VACUUM e VACUUM FULL. A alternativa correta é a que combina as práticas recomendadas: backup físico com pg_basebackup, replicação assíncrona (para não impactar o desempenho) e arquivamento contínuo do WAL para permitir a recuperação pontual.

Alternativa A — ❌ Incorreta

A replicação síncrona garante que não haja perda de dados em caso de falha do servidor primário, mas não torna o backup desnecessário. A replicação protege contra falhas de hardware, mas não contra erros lógicos, corrupção de dados ou desastres que afetem ambos os servidores. O backup é essencial para a recuperação em cenários que a replicação não cobre. Além disso, a replicação síncrona pode impactar o desempenho, pois o primário aguarda a confirmação do standby.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a estratégia mais adequada. O pg_basebackup realiza um backup físico completo do cluster, que é a base para a recuperação. A replicação assíncrona é uma escolha equilibrada, pois não impacta o desempenho das operações de escrita no primário. O arquivamento contínuo do WAL permite a recuperação pontual (point-in-time recovery), ou seja, é possível restaurar o banco até um instante específico, minimizando a perda de dados. Essa combinação é amplamente recomendada pela documentação oficial do PostgreSQL para garantir alta disponibilidade e integridade.

Alternativa C — ❌ Incorreta

Backups exclusivamente lógicos com pg_dump não garantem a recuperação completa do banco em caso de falha de hardware. O pg_dump exporta dados e esquema, mas não captura o estado completo do cluster, como roles, tablespaces, e o WAL. Além disso, a restauração de um backup lógico é mais lenta e não permite recuperação pontual. Para falhas de hardware, o backup físico é o mais adequado.

Alternativa D — ❌ Incorreta

Desativar o WAL é inviável e perigoso. O WAL é essencial para a durabilidade das transações e para a recuperação do banco. Sem ele, qualquer falha pode corromper os dados. Além disso, o WAL é necessário para a replicação e para a recuperação pontual. O espaço em disco e o overhead de escrita são gerenciáveis e justificáveis pela segurança que o WAL proporciona.

Alternativa E — ❌ Incorreta

O VACUUM FULL não deve ser executado diariamente. Ele bloqueia a tabela durante a operação, causando indisponibilidade, e é mais lento que o VACUUM comum. Para a manutenção rotineira, o VACUUM comum (ou o autovacuum) é suficiente. O VACUUM FULL deve ser usado apenas em situações específicas, como após grandes exclusões, e em janelas de manutenção.

Gabarito: letra B