Edição de 17/09: PostgreSQL — backup não prova recuperação
Restaurar em isolamento e reconciliar o ponto escolhido: uma proposta de aceitação que separa ficheiros íntegros de dados utilizáveis.
- Autoria
- Redação Velqory
- Dia recuperado
- 2026-09-17
- Publicação real
- 2026-10-05
- Revisão editorial e verificação
- 05/10/2026 · Europe/Lisbon
- Natureza
- Análise retrospetiva publicada a 5 de outubro; não representa publicação original nessa data. Propostas operacionais originais da Velqory, não testadas; nenhum ensaio ou experiência interna é alegado.
- Revisão
- Revalidar documentação e critérios antes de qualquer intervenção e quando mudar a versão ou a configuração.
Em resumo
Restaurar em isolamento e reconciliar o ponto escolhido: uma proposta de aceitação que separa ficheiros íntegros de dados utilizáveis.
- Identifique a cópia e o ponto pretendido antes do ensaio.
- Separe validação técnica de aceitação operacional.
- Recuse a recuperação com ausências ou efeitos externos por explicar.
Consegue provar o estado que recuperou?
Uma cópia concluída responde a uma pergunta sobre recolha. A direção de operações precisa de outra resposta: que informação poderá voltar a utilizar, em que ponto temporal e com que divergências conhecidas? Esta edição recupera o tema de 17 de setembro como análise retrospetiva; não noticia uma falha nem um ensaio ocorrido nesse dia.
Para responsáveis de bases de dados e operações de uma PME portuguesa, a proposta Velqory é exigir uma prova de recuperação separada do relatório de backup. Outra pessoa deve conseguir identificar a cópia, repetir a seleção do ponto e compreender aquilo que ficou fora da validação.
Integridade não é aceitação dos dados
A documentação PostgreSQL 18 avisa que pg_verifybackup não faz todas as verificações de um servidor em execução e recomenda restauros de teste com confirmação dos dados. Um resultado favorável da ferramenta não substitui essa etapa.
Propomos dois registos: integridade do material recolhido e aceitação da base restaurada. O primeiro fica com a equipa técnica; o segundo exige também o responsável pelos dados. Nenhum deve receber a designação de recuperação comprovada só porque o outro passou. Não apresentamos resultados medidos nem uma garantia de restauro.
Escolha o ponto antes de olhar para o resultado
Segundo o capítulo de PITR, a recuperação por arquivo contínuo exige uma sequência contínua de WAL arquivado desde, pelo menos, o início do backup. O mesmo capítulo manda inspecionar os dados antes de permitir ligações normais.
Proposta original: escreva primeiro o alvo temporal, o fuso horário e a regra de inclusão das operações no limite escolhido. Guarde a identificação da cópia-base, a cobertura de WAL e o ponto efetivamente atingido. Se a cadeia estiver incompleta ou o alvo não estiver demonstrado, classifique o ensaio como falhado, mesmo que o servidor arranque.
Uma fronteira verificável para o laboratório
Propomos um destino independente, com rotas, contas e integrações revistos antes de arrancar a cópia. Quem prepara o restauro deve mostrar que o ambiente não pode enviar notificações reais, executar pagamentos ou receber escritas de clientes. Uma cópia não autoriza a distribuição dos dados.
Defina como preservar o original, retirar o laboratório e eliminar as cópias temporárias segundo a política interna. Este desenho não foi testado e não é um procedimento executável para qualquer instalação. Versões, extensões, armazenamento e serviço alojado devem ser verificados pela equipa responsável.
O dump não representa a hora de chegada
A documentação diz que pg_dump produz um snapshot consistente do início da sua execução. Não confunda esse estado com a hora em que o ficheiro terminou de ser transferido.
Num cenário inteiramente hipotético, a aplicação aceita uma encomenda depois desse início. O dump restaurado pode ser coerente e não conter a encomenda. Propomos reconciliar identificadores com um registo autorizado de operações, assinalando ausências e efeitos externos. Não recrie automaticamente uma cobrança: a ausência na base restaurada não decide o que aconteceu no prestador de pagamentos.
Recuperar exige duas conclusões
A matriz é uma proposta editorial original. Substitua os papéis por nomes e fixe os limites antes do ensaio. Registe duração observada apenas após execução real; o orçamento de tempo acordado não é uma medição.
Peça uma conclusão técnica e outra operacional. Se a reconciliação falhar, preserve a evidência e atribua a correção sem promover o ambiente. Aceitar aquele ponto para aquele serviço não valida todas as bases, todas as cópias ou qualquer incidente. Uma recusa fundamentada é um resultado útil.
Contrato de aceitação do restauro
Proposta Velqory não testada.
| Prova | Responsável | Evidência | Passa / falha |
|---|---|---|---|
| Origem | Administrador da base | Cópia identificada e validação | Passa com origem rastreável; falha com ficheiro desconhecido. |
| Ponto | Responsável de recuperação | Alvo, WAL e ponto atingido | Passa com alvo demonstrado; falha com lacuna. |
| Conteúdo | Operações | Encomendas e totais reconciliados | Passa com diferenças aceites; falha com ausência inexplicada. |
| Isolamento | Infraestrutura | Revisão de ligações | Passa sem efeitos externos; falha com acesso a produção. |
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.