APRENDER. PRATICAR. EVOLUIR.O estado externo não recua com o backup
O produtor fictício guarda uma ordem como pending antes do backup. Mais tarde, o receptor sintético aceita a ordem e o produtor marca-a como sent. Ao restaurar a cópia antiga, o produtor volta a mostrar pending, mas o receptor continua a ter um efeito confirmado. No laboratório, ambos são bases locais separadas; não existe chamada a um parceiro real. O exemplo mostra porque o marker restaurado não é uma verdade global sobre entrega. Numa recuperação de batch, identifica estados que ficaram fora do conjunto restaurado, preserva identificadores e consulta confirmações autorizadas. Reiniciar automaticamente todos os itens pendentes pode repetir trabalho que já produziu efeito.
Uma repetição precisa de identidade e conteúdo
O receptor do modelo associa order-1 ao montante 100. Uma repetição com o mesmo identificador e conteúdo devolve duplicate, conservando um efeito. O mesmo identificador com 101 é recusado como conflito. Um identificador novo com 100 produz outro efeito: o receptor não sabe que se pretendia repetir a operação anterior. Estas regras são um contrato explícito do modelo, não uma garantia universal de APIs bancárias. Também pressupõem que o histórico ainda existe. Se o backup recuar além da retenção de deduplicação, a chave sozinha pode ser insuficiente. Define a janela de replay, a evidência disponível e o tratamento de conflitos antes de autorizar o reenvio.
Escrever num ensaio sem gerar um efeito real
O write probe insere uma terceira ordem no destino isolado, observa-a dentro da transação e faz rollback. Depois continuam a existir duas ordens e a reconciliação passa. O laboratório confirma também que a origem e o artefacto de backup ficaram iguais. Isto demonstra uma operação local reversível com os privilégios do processo de teste. Não valida IAM, chaves, ligações a parceiros ou a conta real da equipa RUN. Além disso, rollback de SQL não desfaz automaticamente um pedido externo já enviado. Num ensaio de aplicação, controla os destinos de saída antes de ativar consumidores e usa operações cujos efeitos e limpeza estejam definidos no plano aprovado.
Medir até à função acordada
Num exercício fictício, a indisponibilidade começa às 09:00. O restore acaba às 09:20, a configuração às 09:28 e a validação funcional às 09:35. Se o compromisso é serviço validado em 30 minutos, o resultado é 35, com um desvio de cinco. Mantém os marcos intermédios para perceber o caminho que atrasou a recuperação. Não escolhas o marco mais favorável depois do ensaio. No planeamento, considera sobreposição: restore de 20 minutos e identidade de 12 podem correr em paralelo; uma validação de oito que depende de ambos termina aos 28, na ausência de outras esperas. Essa conta é uma estimativa e precisa de observação no ambiente relevante.
Aceitar capacidade e operação, além dos dados
Uma base correta não garante capacidade para o fluxo de entrada. No exemplo fictício, chegam 50 ordens por minuto e o destino recuperado processa 20. A fila cresce 30 por minuto, mesmo que cada ordem processada esteja correta. A equipa deve comunicar esse modo degradado, estimar o efeito no cut-off e discutir contenção ou capacidade adicional. O ensaio também precisa da identidade que operará o serviço: uma conta pessoal privilegiada pode esconder permissões em falta na conta RUN. Associa cada conclusão ao que foi observado. O laboratório de duas ordens não estabelece throughput de produção; fornece apenas uma estrutura para formular perguntas de aceitação mais completas.
Fechar com proteção e risco residual visíveis
O relatório de recuperação deve permitir distinguir função reposta, reconciliação concluída, objetivos cumpridos ou desviados e proteção ainda pendente. Se o novo destino já recebe escritas mas não tem backup validado, a primeira recuperação não resolveu a exposição à próxima falha. Regista responsável, prazo, evidência esperada e quem pode aceitar o risco temporário. Um modo degradado aprovado não equivale a fingir ausência de risco. No handover fictício, a equipa entrega os IDs reconciliados, os resultados dos controlos, os marcos temporais e as ações por concluir. Depois de corrigir uma lacuna, repete o controlo correspondente; a existência de uma tarefa fechada não substitui a observação do resultado.
original ID + original content -> duplicate, one effect
original ID + changed content -> conflict
new ID + original content -> second effect
# Synthetic local receiver contract, not a universal API guarantee.O produtor restaurado mostra pending para uma ordem já executada. A repetição com o ID original conserva um efeito; um novo ID cria um segundo efeito no receptor sintético.
Armadilhas comuns
Reenviar com novos IDs; assumir que rollback local desfaz efeitos externos; medir só o restore; usar uma conta privilegiada como prova da autonomia RUN.
Tópicos relacionados: Restauro: ponto recuperado e integridade · RTO, RPO e dependências · Ensaios e validação funcional
A retoma exige reconciliar o que aconteceu fora do backup e aceitar explicitamente função, tempo, capacidade e proteção.
Referência: Test disaster recovery implementation · DR recovery 2026-09; PostgreSQL 18, etcd 3.6 and selected AWS/Azure behavior