APRENDER. PRATICAR. EVOLUIR.Comparar valores e invariantes
A primeira verificação lê ids, referências e unidades no destino e compara-os com o ponto exportado. Uma contagem de duas linhas seria compatível com valores errados ou referências trocadas; por isso, não basta como critério único. O laboratório confirma as linhas A=40 e B=60 antes de executar novas escritas de aceitação. Define quais invariantes importam no serviço: totais, relações, estados ou intervalos autorizados. Distingue dados recuperados de dados criados pelos testes posteriores, para que o próprio ensaio não pareça uma divergência. Em produção, a reconciliação funcional precisa de um responsável e de critérios acordados.
Testar o caminho runtime e o owner
Depois do restauro completo, a tabela pertence a deploy_owner e uma ligação real como runtime consegue ler o total 100. A mesma identidade insere uma nova referência com RETURNING id. Estas operações exercitam schema, tabela, sequência e leitura do identificador, indo além de uma consulta administrativa. Noutra base, --no-owner --no-acl recupera os mesmos valores, mas o owner passa a dr_lab e runtime recebe 42501. O contraste demonstra que portabilidade de dados e preservação de autorização são objetivos distintos. Se houver remapeamento intencional no destino, define os novos grants e volta a testar com as identidades previstas.
Preservar a semântica das sequências
Na origem, duas linhas têm ids 1 e 2. Uma chamada adicional a nextval e uma inserção posteriormente revertida avançaram a sequência até 4. O dump preserva esse estado; a primeira inserção runtime no destino recebe 5. Não é um erro de contagem nem uma linha desaparecida durante o restauro. Sequências podem ter lacunas e não funcionam como contadores transacionais sem falhas. Evita substituir o estado recuperado por max(id) sem analisar contratos externos, chamadas já efetuadas e risco de reutilização. O laboratório demonstra esta sequência controlada, sem concorrência nem garantia de ordenação temporal de transações de negócio.
Confirmar rejeições e integridade
Uma recuperação utilizável deve preservar também operações que não são permitidas. Após uma inserção válida, o ensaio tenta units negativo e uma referência A duplicada. As constraints restauradas rejeitam as operações com 23514 e 23505; a contagem permanece em três linhas. Regista o diagnóstico estruturado e confirma o estado, em vez de tratar qualquer mensagem de erro como êxito do teste negativo. Este conjunto não cobre todas as constraints, triggers ou funções possíveis de outra aplicação. A matriz real deve derivar do schema e dos invariantes do serviço, incluindo efeitos externos que um rollback SQL não consegue desfazer.
Distinguir estrutura e dados numa recuperação parcial
Numa terceira base de destino, --data-only falha porque ainda não existem os objetos da aplicação. O ensaio aplica então --schema-only, confirma que ledger existe vazia e aplica os dados do mesmo arquivo. Recupera duas linhas, total 100 e próximo valor de sequência 5. Esta ordem demonstra uma composição compatível específica; não prova que qualquer dump parcial seja independente. Se escolheres tabelas ou schemas, inventaria dependências e objetos auxiliares que o filtro pode excluir. Não mistures estrutura de uma versão com dados de outra sem validação explícita de colunas, constraints, tipos e transformações necessárias.
Fechar a aceitação com limites claros
Após a recuperação, ANALYZE atualiza informação usada pelo planeador; o ensaio confirma uma estimativa de duas linhas. Esse resultado não demonstra latência aceitável, throughput nem cumprimento de RTO. Para o serviço real, mede o percurso completo: obtenção do backup, preparação do destino, restauro, reconciliação, aplicação e decisão de retoma. Identifica também como satisfazer RPO se existirem alterações posteriores ao ponto recuperado. Aqui não se executaram PITR, crash, restore remoto, pool, carga ou workshop humano. O relatório deve guardar o que passou e transformar os pontos ainda não exercitados em trabalho de aceitação, sem apresentar o laboratório como recuperação de produção concluída.
# Target database and required roles already prepared in the owned lab.
pg_restore -h /owned/target/socket -U dr_lab -d restored --single-transaction original.dump
# Connect as runtime for application-path acceptance:
# SELECT id, ref, units FROM app.ledger ORDER BY id;
# INSERT INTO app.ledger(ref, units) VALUES ('recovered',7) RETURNING id;
# ANALYZE is performed by the administrator after recovery.A tabela recuperada tem ids 1 e 2, mas a primeira inserção runtime devolve id 5 porque o estado da sequência foi preservado.
Armadilhas comuns
Aceitar apenas pela contagem; ignorar grants; reiniciar sequências por max(id); tratar ANALYZE como prova de SLA.
Tópicos relacionados: Recuperação lógica e dependências · Aceitação operacional e evidência
Recuperação utilizável exige verificar as operações que o serviço precisa, com limites e lacunas do ensaio registados.
Referência: Archive restoration and error handling · PostgreSQL 18 reference semantics;18.6 current stable at review