APRENDER. PRATICAR. EVOLUIR.1. Definir o serviço que tem de regressar
Começa pelo resultado que a área de negócio precisa de recuperar. Numa aplicação fictícia de fundos, conseguir consultar posições não demonstra que é possível receber um ficheiro, validar movimentos e reconciliar o processamento. Define operações, dependências e critérios de aceitação antes do ensaio. Se o job demora 22 minutos e os testes sequenciais necessários mais 18, o tempo observado é 40 minutos para esse âmbito. Um objetivo de 30 minutos não foi atingido. O cálculo é uma convenção operacional do exercício, não uma métrica universal AWS. Regista também o instante do ponto recuperado e a diferença para os dados esperados; terminar depressa não resolve perda de dados excessiva. Nomeia quem pode aceitar o serviço ou ativar a contingência aprovada.
2. Selecionar recursos e pontos recuperáveis
Um plano de restore testing precisa de seleção de recursos; o horário não faz essa atribuição. Na seleção por tags, as tags do recovery point mais recente ajudam a escolher o recurso. Escolher depois um ponto aleatório não obriga esse ponto a ter as mesmas tags. Um recurso sem ponto elegível na janela não participou num restauro bem-sucedido: ficou de fora. Considera a execução efetiva ao interpretar a janela de seleção. Uma execução tardia pode deixar um ponto fora do intervalo mesmo que parecesse elegível no horário previsto. Para o gestor, entrega uma lista de recursos pretendidos, selecionados, excluídos e restaurados. Pede uma justificação para cada diferença antes de apresentar o ensaio como cobertura da aplicação completa.
3. Diagnosticar contexto e permissões
O ambiente de ensaio pode não ter a VPC por omissão que o metadata inferido espera. Consulta o metadata previsto, compara-o com os valores usados no job e define a subnet de ensaio adequada. Não repitas indefinidamente o mesmo pedido à espera de uma rede diferente. Se AWS Backup não consegue assumir a role, começa pela relação de confiança; acrescentar ações à política de permissões não corrige quem pode assumir a identidade. Para backups cifrados, verifica permissões e políticas das chaves relevantes para o backup e para o recurso restaurado. O acesso do operador à consola não demonstra acesso da role. No runbook, liga cada mensagem de erro à equipa responsável e ao dado necessário para confirmar a correção.
4. Validar antes de publicar sucesso
O estado COMPLETED do restauro pode acionar um workflow próprio via EventBridge. Faz esse workflow executar os testes acordados e só depois publicar o resultado com PutRestoreValidationResult. O estado de validação definido não pode ser alterado; SUCCESSFUL não serve como marcador provisório enquanto a reconciliação decorre. Guarda logs e identificadores que permitam explicar uma falha funcional. Os recursos de restore testing são temporários e entram em limpeza após validação ou fim da janela. Nos recursos que recebem a tag awsbackup-restore-test, removê-la pode impedir a limpeza automática. O exercício local abaixo avalia evidência fictícia e nunca chama a API. Se um teste de negócio falha, mantém a aceitação pendente e investiga sem converter a existência do recurso em prova de prontidão.
5. Rever retenção antes da irreversibilidade
Governance permite remover Vault Lock com autorização suficiente. Em compliance, usa LockDate para saber quando termina a possibilidade de mudar o lock; Locked=true por si só não descreve essa fase. Revê retenções e custos com FinOps antes desse momento, sobretudo pontos com Always. Os limites de retenção rejeitam novos jobs incompatíveis e não reescrevem o ciclo dos pontos anteriores. No exercício de mudança, uma cópia de sete dias para um vault com mínimo de trinta falha; não recebe trinta automaticamente. Proteção contra eliminação também não prova capacidade imediata de restauro: uma AMI desativada pode impedir a operação. O plano de aceitação deve verificar retenção, acessibilidade e funcionalidade como evidências separadas.
6. Ensaiar a recuperação entre contas
A partilha de um logically air-gapped vault usa contas individuais, não uma OU como destinatário. A conta destinatária pode consultar e restaurar os pontos partilhados, mas não criar cópias deles; mais permissões IAM não eliminam essa restrição. A escolha atual de cifragem permite a chave AWS-owned por omissão ou uma chave gerida pelo cliente na criação, sem trocar a chave do vault depois. Transforma estas restrições em perguntas de desenho: quem conserva a cópia, quem restaura e quem demonstra acesso às dependências? Num ensaio internacional, distribui responsabilidades e critérios de passagem entre turnos. Resume o resultado por serviço, ponto recuperado, operações validadas, tempo observado e lacunas. Estas práticas são exemplos originais para APS, não procedimentos internos de qualquer banco.
# Original fictional acceptance model, not the AWS validation API.
# No credentials, network calls, or changes to any backup.
def acceptance(job_complete, checks, restore_minutes, validation_minutes, objective):
if not job_complete:
return "restore-incomplete"
if not checks or not all(checks.values()):
return "functional-evidence-incomplete"
if restore_minutes + validation_minutes > objective:
return "time-objective-missed"
return "accept-within-stated-scope"
assert acceptance(False, {}, 0, 0, 30) == "restore-incomplete"
assert acceptance(True, {}, 22, 0, 30) == "functional-evidence-incomplete"
assert acceptance(True, {"read": True, "reconcile": False}, 22, 18, 30) == "functional-evidence-incomplete"
assert acceptance(True, {"reconcile": True}, 22, 18, 30) == "time-objective-missed"
assert acceptance(True, {"reconcile": True}, 22, 18, 40) == "accept-within-stated-scope"
print("five recovery-evidence cases passed; no validation result was published")
Um restauro termina, mas a reconciliação de fundos falha. A equipa mantém a aceitação pendente e comunica impacto e contingência.
Armadilhas comuns
COMPLETED como serviço disponível; pontos excluídos como testados; Locked como prova do fim do grace time; permissões extra como solução universal.
Tópicos relacionados: Resposta a incidentes · Aceitação e passagem a RUN
O restauro só sustenta a aceitação no âmbito funcional e temporal que foi demonstrado.
Referência: Restore testing · SCS-C03