pg_dump y pg_restore: como fazer e verificar backups do PostgreSQL
Publicado em 2026-10-26 por frfrand
Cópia lógica e restauração no PostgreSQL com comandos seguros
«Temos backups» não significa muito até que alguém precise restaurar um. Com PostgreSQL, pg_dump permite criar cópias lógicas e pg_restore recupera-las quando você usou formatos compatíveis. O importante é verificar o procedimento.
A ideia é resolver um problema de dados ou implantação que aparece em aplicações reais. Vamos ver o conceito sem rodeios, um exemplo de implementação e o que verificar antes de levá-lo à produção.
O que faz pg_dump e pg_restore
Uma cópia lógica exporta objetos e dados do banco, não todo o estado do servidor PostgreSQL nem necessariamente funções globais ou configurações externas. Para bancos muito grandes ou recuperação em um instante específico, podem ser necessários backups físicos e WAL/PITR.
Não basta repetir uma receita se você não entende quem lê os dados, de qual processo e com quais permissões. Em um aplicativo com reservas, faturas ou usuários, uma condição de corrida ou uma política de acesso mal feita pode ser mais grave que uma API lenta.
Um exemplo concreto
# Formato custom en un entorno autorizado
pg_dump -h 127.0.0.1 -U app -F c -f /backups/app-20261026.dump app
# Inspeccionar contenido de la copia
pg_restore -l /backups/app-20261026.dump | head
# Restaurar en una base de PRUEBA ya creada
pg_restore -h 127.0.0.1 -U restaurador -d app_pruebas --no-owner /backups/app-20261026.dumpOs nomes, tabelas e chaves deste exemplo são ilustrativos. Teste primeiro em um banco ou ambiente de ensaio e adapte permissões, índices e versões. Quando houver operações de gravação, não execute consultas de exemplo sobre dados de clientes sem revisar o que elas modificam.
Passo a passo
- Escolha o destino de armazenamento com permissões, criptografia e retenção adequados.
- Crie a cópia em um formato apropriado e verifique se a operação terminou sem erro.
- Guarde a versão do motor e o procedimento de restauração junto ao backup.
- Restaure em um banco de teste isolado e verifique tabelas, relacionamentos e dados-chave.
- Programe verificações recorrentes, não apenas a geração noturna do arquivo.
No final, não fique com «o SQL não deu erro». Verifique o efeito real pela API e com testes de concorrência ou permissões, conforme o caso. Em bancos de dados, há erros que só aparecem quando dois usuários fazem algo ao mesmo tempo.
Exemplo de projeto de trabalho
Uma plataforma de aluguéis tem reservas e entradas pagas. Antes de uma atualização de esquema, faça uma cópia consistente, restaure-a em staging e teste se o aplicativo consegue iniciar com esses dados.
Esse cenário ajuda a distinguir desempenho de consistência. Acelerar uma consulta não serve se permitir criar duas reservas para uma única vaga, nem um banco enorme resolve o fato de o backend permitir consultar dados de outro cliente.
O erro típico
Não restaure uma cópia de teste em produção por engano. Para bancos ativos, o tamanho, a consistência e a janela de recuperação podem exigir uma estratégia diferente do despejo completo diário.
Também convém ter um plano de recuperação. Antes de mexer no esquema, usuários ou políticas, guarde uma cópia verificável ou migração reversível e comprove que o aplicativo pode continuar funcionando durante a mudança.
Como resolveria com ArduMaker?
Ao gerenciar PostgreSQL e VPS pelo ArduMaker, documente onde as cópias são guardadas, quem acessa e quanto tempo você leva para recuperar a API. O painel não substitui o simulacro de restauração.
O ArduMaker permite implantar serviços a partir do Git e trabalhar com bancos e processos dentro do VPS. O painel não substitui a lógica do seu aplicativo: transações, permissões e validações devem estar corretamente projetadas no código e no banco de dados.
Três verificações antes de publicar
Integridade: se uma requisição se repetir ou falhar no meio do caminho, os dados terminam em um estado válido?
Segurança: um usuário autenticado pode acessar apenas suas informações, e a API utiliza uma identidade de banco com permissões mínimas?
Recuperação: você sabe restaurar os dados e reverter a versão de código compatível se uma atualização der errado?
Se você puder responder a essas três perguntas com provas, seu backend está bastante mais preparado do que quando você apenas olhou se o endpoint devolvia 200.
Recursos para aprofundar
Para encerrar: escolha a solução mais simples que permita manter dados corretos, seguros e recuperáveis. O desempenho vem depois de medir.