APRENDER. PRATICAR. EVOLUIR.Publicar e observar uma segunda identidade
Na montagem NFS real, o produtor sintético escreve delivery.tmp, aplica o modo pretendido e renomeia para delivery.ready. O nome inicial deixa de existir e o final fica disponível. Uma segunda identidade lê 23 bytes e confirma o hash esperado. O guião acrescenta retry.ready com a mesma instrução e conta dois ficheiros para um identificador. Não existe consumidor de negócio implementado: o resultado não diz quantas operações financeiras seriam executadas. A oficina pede ao aluno que desenhe a fronteira entre publicação, leitura e processamento. Define também como o consumidor reconhece uma intenção repetida e o que acontece quando o mesmo identificador reaparece com conteúdo diferente. Um nome novo, isoladamente, não resolve esse contrato.
Raciocinar sobre uma confirmação perdida
O caso de falha de confirmação é uma discussão guiada, não uma falha injetada no laboratório. Depois de um erro NFS, não assumes que rename ficou sem efeito: compara nomes e conteúdo e consulta o estado do consumidor antes de repetir. Preserva a identidade da intenção para relacionar tentativas. Se a consulta estiver pendente, comunica um estado incerto com responsável e prazo de revisão, em vez de inventar sucesso ou falha. Outra situação altera o mecanismo de publicação: temporários colocados noutro filesystem podem fazer rename devolver EXDEV. Substituir a operação por cópia direta para o nome final exige rever quando o consumidor pode começar a ler. Estas decisões pertencem ao contrato da aplicação e devem ser ensaiadas com ela.
Medir recuperação por dados e serviço útil
Num exemplo fictício, o incidente ocorre às 12:00 e o último ponto recuperável confirmado é 11:40. Um RPO de dez minutos não está demonstrado por esse ponto de vinte minutos, mesmo que a restauração seja rápida. O RTO avalia outro compromisso: o tempo até ao serviço útil segundo critérios acordados. A oficina usa uma linha temporal com incidente, recuperação dos ficheiros, reconciliação e aceitação do consumidor. Se as confirmações da aplicação estiverem mais adiantadas do que os ficheiros restaurados, compara identificadores antes do replay. O laboratório em RAM não testa persistência após crash nem mede estes objetivos. Os tempos dos cenários são dados fictícios para treinar a decisão e precisam de evidência própria num ensaio representativo.
Decidir cutover e rollback com o delta visível
O cenário final tem 18 entregas criadas no novo destino após cutover, das quais sete têm confirmação. Antes de voltar à origem, contém escritores e consumidores conforme o plano aprovado, preserva o inventário e classifica cada identidade como confirmada, não processada ou incerta segundo evidência. Repor DNS não elimina efeitos de negócio nem acrescenta à origem os dados novos. A equipa precisa de acordar o ponto de retoma e os responsáveis pela reconciliação. Na passagem para RUN em inglês, inclui o resultado observado, o que falta provar, os critérios de rollback e quem autoriza reabertura. Um mount ativo e hashes iguais são partes úteis da evidência, mas não encerram os critérios funcionais ou de recuperação ainda pendentes.
# Read recorded evidence, without starting services or changing mounts.
python3 - <<'PY'
import json
from pathlib import Path
r=json.loads(Path("content/labs/nas-nfs/evidence.json").read_text())
for key in ["publishByRename", "consumerReadsPublishedBytes",
"twoNamesOneInstruction", "unmountRevealsLocalDirectory"]:
print(key, r["checks"][key])
PYDuas entregas têm nomes diferentes mas a mesma instrução. Num cutover fictício, 18 entregas novas e sete confirmações exigem reconciliação antes do rollback.
Armadilhas comuns
Usar hashes como prova de processamento, repetir com identidade nova, confundir RPO com RTO ou reverter o endpoint ignorando dados novos.
Tópicos relacionados: Idempotência e resultados incertos · Disaster recovery e passagem para RUN
Uma entrega só fica aceite no âmbito demonstrado. Recuperação e rollback precisam de reconciliar dados e efeitos do consumidor.
Referência: Disaster Recovery of Workloads on AWS: introduction · DR NAS 2026-09; selected Linux NFS, Samba, Windows SMB and ONTAP behavior