APRENDER. PRATICAR. EVOLUIR.Definir o contrato antes de exportar
Um backup lógico deve responder a uma necessidade concreta: migração, cópia de diagnóstico ou recuperação de objetos. No laboratório, o contrato inclui duas linhas, respetivos valores, constraints, estado da sequência, owner e acesso runtime. Usam-se dois clusters PostgreSQL 18.6 descartáveis, ambos locais e com sockets privados. Não se mede o tempo de recuperação de uma base representativa nem se ensaia WAL ou PITR. Antes de usar o exemplo no trabalho, identifica volume, extensões, dependências externas e objetivos de recuperação do serviço. O êxito deste pequeno contrato não demonstra, por si, que a estratégia serve uma base de produção inteira.
Inspecionar um arquivo custom
pg_dump produz um arquivo custom e pg_restore --list confirma entradas de dados e estado de sequência. A listagem ajuda a comparar o inventário esperado com o artefacto produzido. Não executa os comandos no destino, não verifica roles disponíveis e não prova que a aplicação consiga funcionar depois. O laboratório regista o código de saída e mantém o arquivo durante várias tentativas de restauro. Um hash antes e depois confirma que essas tentativas não alteraram os bytes. Essa igualdade não demonstra autenticidade da origem, atualidade dos dados ou correção funcional; são propriedades diferentes que precisam de evidência própria.
Fixar a comparação no ponto exportado
Antes do dump, A tem 40 unidades e B tem 60. Depois de o comando terminar, a origem altera A para 999 e acrescenta late com 5 unidades. O destino recuperado contém A=40 e B=60, sem late. Compará-lo apenas com o total atual da origem produziria um falso diagnóstico de restauro incorreto. Regista o ponto de referência e as alterações posteriores que exigem reconciliação. Este ensaio ordena as escritas depois do dump e não demonstra concorrência durante a exportação. Também não permite escolher arbitrariamente uma hora posterior: recuperar essas alterações requer outro mecanismo ou processo autorizado.
Separar dados da base e objetos globais
O arquivo da base referencia deploy_owner e runtime, mas o novo cluster não contém essas roles. A primeira tentativa falha por falta do owner. Em paralelo, pg_dumpall --globals-only produz um script com definições globais, sem a tabela ledger. O guião inspeciona esse script, usando --no-role-passwords, e cria apenas as duas roles fictícias necessárias no destino. Não executa o conjunto global exportado. Numa recuperação real, revê identidades, memberships, tablespaces e configurações em função do destino autorizado. Copiar cegamente um conjunto global pode recriar capacidades que não pertencem ao ambiente de recuperação.
Escolher o comportamento perante erro
A tentativa inicial usa --single-transaction. A ausência de deploy_owner provoca uma saída de erro; depois, o catálogo do destino confirma que o schema app não ficou criado. A base restored, preparada antes do comando, continua a existir. Esta diferença delimita o que a transação do restauro abrange. Não extrapoles a observação para qualquer execução com outras opções: parar no primeiro erro não é o mesmo que desfazer comandos já confirmados. Regista opções, diagnóstico e estado final. Para volumes maiores, avalia também custos de uma transação longa, locks e incompatibilidades com paralelismo antes de adotar o mesmo modo.
Preparar uma decisão de repetição
Depois de identificar a dependência em falta, o laboratório cria as roles de destino e repete o mesmo arquivo na base que ficou sem objetos da aplicação. A segunda execução termina com sucesso. Uma operação real deve confirmar primeiro o estado deixado pela tentativa anterior e escolher conscientemente um destino limpo ou uma reparação controlada. Não acrescentes --clean por rotina sobre uma base desconhecida, pois pode remover objetos. Mantém origem, destino e parâmetros explícitos no runbook. O ensaio não reutiliza credenciais reais, não liga a redes externas e elimina apenas os clusters e ficheiros temporários que ele próprio criou.
# Only synthetic data in the disposable lab. Use owned socket paths.
pg_dump -h /owned/source/socket -U dr_lab -d original -Fc --compress=0 -f original.dump
pg_restore --list original.dump
pg_dumpall -h /owned/source/socket -U dr_lab --globals-only --no-role-passwords -f globals.sql
# The lab inspects globals.sql; it does not execute this script on the target.O arquivo contém duas linhas com total 100. Alterações posteriores levam a origem a três linhas e total 1064, sem modificar o backup.
Armadilhas comuns
Confundir listagem com restauro; assumir que pg_dump cria roles globais; comparar o destino com uma origem que já mudou.
Tópicos relacionados: Recuperação lógica e dependências · Aceitação operacional e evidência
O arquivo é uma parte do plano: dependências, opções, ponto dos dados e critérios de aceitação precisam de ser explícitos.
Referência: Logical database export · PostgreSQL 18 reference semantics;18.6 current stable at review