APRENDER. PRATICAR. EVOLUIR.1. Classificar a perda antes de acionar recuperação
Num serviço fictício de processamento de fundos, um ficheiro pode desaparecer por eliminação, ser substituído por uma versão incorreta ou ficar inacessível devido a uma falha regional. Estes incidentes exigem decisões diferentes. Uma réplica geográfica ajuda perante indisponibilidade da região, mas pode receber a mesma alteração indesejada que atingiu a origem. Antes de selecionar a operação, regista o objeto afetado, a última versão aceite pelo negócio, o intervalo de alterações suspeitas e a disponibilidade do serviço. Separa restaurar acesso de restaurar o estado correto dos dados. Um endpoint que voltou a responder pode continuar a servir um ficheiro incorreto. No projeto, exige critérios de aceitação para os dois resultados e atribui ao negócio a validação do conteúdo recuperado, com apoio da equipa técnica para integridade e rastreabilidade.
2. Identificar a unidade que foi eliminada
Blob soft delete e container soft delete protegem unidades diferentes. Num exercício, o operador elimina um container inteiro, embora a equipa tenha ensaiado apenas a recuperação de blobs individuais. O runbook deve identificar essa diferença antes de executar comandos. Se existem versões anteriores de um blob, identifica qual corresponde ao estado pretendido e como voltará a ser a versão atual. Com versioning ativo, undelete não transforma por si só uma versão anterior na versão atual; a recuperação pode exigir copiá-la para esse efeito. Regista o identificador da versão e valida tamanho, hash e conteúdo funcional. Evita escolher apenas a versão mais recente quando o incidente é uma substituição incorreta. As permissões de recuperação também devem ser ensaiadas sem conceder acesso permanente desnecessário ao suporte.
3. Preparar o ponto de recuperação antes do incidente
Point-in-time restore tem requisitos e limites de compatibilidade: não basta ativá-lo depois de descobrir uma corrupção. A configuração exige soft delete, change feed e versioning; a proteção não cria histórico anterior à ativação. Confirma o tipo de conta, namespace e tiers suportados na documentação atual. A operação pode bloquear acessos aos intervalos em recuperação, pelo que a janela de indisponibilidade deve entrar no plano. No caso fictício de uma carga que alterou milhares de posições, o gestor pede à equipa que delimite o conjunto afetado e escolha um instante UTC anterior à carga. A aprovação inclui o impacto sobre alterações legítimas posteriores, a evidência de que o ponto existe e a validação após recuperação. Não reutilizes este procedimento para recuperar a eliminação de um container.
4. Interpretar Last Sync Time como limite de certeza
Numa falha regional, a replicação assíncrona cria uma janela de incerteza. Last Sync Time permite distinguir escritas anteriores, cuja presença na réplica secundária está garantida pelo serviço, das posteriores, que podem ainda não estar lá. Não significa que todas as escritas posteriores se perderam. Num exemplo fictício, o último instante confirmado é 14:00 UTC e há operações registadas até 14:07. A equipa identifica essas operações como conjunto a reconciliar, preserva identificadores e consulta o resultado recuperado antes de repetir trabalho. O modelo Python usa minutos inteiros e um registo de operações fictício para separar conjuntos; não consulta Azure nem calcula uma perda real. A decisão de failover precisa de um responsável que aceite o risco conhecido e estabeleça como tratar resultados ainda indeterminados.
5. Completar failover com reposição de proteção
Após um failover não planeado gerido pelo cliente, a nova região primária fica com redundância local. Recuperar serviço não encerra o plano de resiliência: é preciso planear a reposição de redundância geográfica, acompanhar a replicação e considerar custos. Um exercício planeado tem condições diferentes, incluindo disponibilidade das regiões e compatibilidade com funcionalidades ativas. Não desatives proteção de dados apenas para fazer um ensaio passar sem analisar o intervalo de exposição criado. No handover, mantém uma tarefa separada para confirmar o estado final de proteção, com owner e evidência. Se o serviço permanece temporariamente com menor resiliência, essa exceção deve ter prazo e acompanhamento. O regresso à região original é outra operação planeada, com critérios próprios de integridade, acesso e decisão.
6. Alinhar retenção, custo e evidência de recuperação
Retenção operacional e retenção exigida pelo negócio precisam de ser compatíveis com as políticas de eliminação. Uma equipa de FinOps pode propor apagar versões antigas para reduzir custo, enquanto uma equipa de controlo precisa de recuperar ficheiros de um fecho anterior. O projeto deve conciliar ambos os requisitos com datas concretas e exemplos de recuperação. Não assumes que a janela de point-in-time restore elimina automaticamente todas as versões antigas: revê as regras de lifecycle aplicadas às versões e o efeito de soft delete. Num ensaio, escolhe um objeto conhecido, altera-o, recupera o estado esperado e compara a evidência funcional. Documenta o tempo medido e as limitações do ensaio. Uma execução pequena bem-sucedida não demonstra o tempo de recuperação de todo o volume de produção.
writes = [("A", 837), ("B", 839), ("C", 843), ("D", 847)]
last_sync = 840 # fictional UTC minute of day
confirmed = {key for key, minute in writes if minute < last_sync}
uncertain = {key for key, minute in writes if minute >= last_sync}
assert confirmed == {"A", "B"}
assert uncertain == {"C", "D"}
assert confirmed.isdisjoint(uncertain)
assert confirmed | uncertain == {key for key, _ in writes}
recovered = {"A", "B", "C"} # hypothetical observed result, not inferred from LST
assert uncertain - recovered == {"D"}
print("five fictional reconciliation checks passed; no Azure loss measured")
Caso fictício: a região falha às 14:07 e Last Sync Time é 14:00. O serviço é recuperado, mas sete minutos de instruções ficam sob reconciliação. O encerramento do incidente exige resultados confirmados e um plano para repor redundância geográfica.
Armadilhas comuns
Confundir réplica com histórico; usar proteção de blobs para eliminar o risco de apagar containers; tratar dados posteriores a Last Sync Time como perda certa; encerrar sem repor redundância.
Tópicos relacionados: RPO e RTO · Reconciliação e idempotência · FinOps e retenção
Recuperação exige restaurar dados corretos, confirmar resultados de negócio e repor a proteção acordada.
Referência: Blob point-in-time restore · AZ-305 objectives 2026-04-17