APRENDER. PRATICAR. EVOLUIR.Escolher um ponto recuperável com significado de negócio
Um backup concluído não define sozinho o ponto que o negócio pode aceitar. Em RDS, PITR cria uma nova instância e deixa a origem inalterada; consulta a janela recuperável e LatestRestorableTime. Se o último ponto recuperável observado é 09:57 e a interrupção ocorreu às 10:03, o intervalo é de seis minutos. Isto mede exposição temporal no exemplo, não prova quais as ordens perdidas. Para uma eliminação lógica às 09:50, escolher simplesmente o ponto mais recente pode trazer a eliminação de volta. Identifica um ponto anterior ao erro e planeia reconciliar movimentos legítimos posteriores. Em SQL Server, PITR de várias bases da mesma instância pode deixar transações entre bases inconsistentes. Inclui os invariantes que atravessam bases ou sistemas na validação. O owner funcional deve explicar quais os registos que precisam de concordar antes de reabrir o serviço.
Reconstruir o contexto de execução do destino
Restaurar dados não demonstra que a aplicação encontra o destino nem que o destino tem as configurações necessárias. Confirma rede, grupos de segurança, identidade, parâmetros e opções do motor. Um restauro de snapshot usa o grupo de parâmetros predefinido se não escolheres outro; isso não transporta automaticamente customizações. Opções persistentes exigem tratamento específico, como TDE em Oracle. Prepara uma configuração revista para o ambiente de recuperação, sem abrir acesso global para ultrapassar falhas de ligação. O estado Available também pode anteceder o carregamento de todos os dados em background. Mede acessos representativos, sobretudo ao conjunto usado no fecho, antes de prometer o desempenho normal. No ensaio, compara a primeira execução com a repetição e regista carga, configuração e conjunto de dados. Um teste de login não prova reconciliação, desempenho ou conectividade de todas as interfaces.
Distinguir restauro técnico de validação funcional
AWS Backup restore testing permite ensaios periódicos com seleção de recursos e recovery points. A seleção precisa de representar o âmbito de recuperação; um recurso omitido não fica testado por associação ao projeto. O mecanismo de validação pode reagir à conclusão do restauro e comunicar um resultado, mas a tua lógica tem de executar os critérios de aceitação. Enviar SUCCESSFUL sem verificar o recurso apenas regista uma declaração. No caso fictício, o teste deve ler posições, comparar totais esperados e confirmar que nenhuma chamada externa de produção foi emitida. Guarda o resultado com o identificador do job e do recovery point. O ambiente de teste é temporário: existe uma janela para validar e limpeza posterior. Não o uses como destino permanente de disaster recovery. Verifica também falhas de limpeza e o custo de recursos que permanecem, preservando primeiro a evidência necessária.
Proteger a recuperabilidade além da retenção
Vault Lock distingue governance, removível com permissões adequadas, de compliance, cuja configuração fica imutável depois do grace time. Revê retenção e custos antes desse limite; novos jobs incompatíveis com a retenção configurada podem falhar. Não confundas impossibilidade de apagar um recovery point com possibilidade demonstrada de o restaurar. Chaves KMS e permissões continuam a importar. Para snapshots RDS, a cifragem segue a base de origem; não assumas que escolher uma chave no vault recifra automaticamente todos os tipos de backup. No exercício, o recovery point existe mas a função de recuperação não obtém acesso à chave necessária. O resultado é um risco de restauro, mesmo com retenção protegida. O PM atribui owners para chave, backup, ambiente e validação, com datas de ensaio e evidência. A decisão final junta ponto recuperável, tempo funcional, integridade, acesso e capacidade operacional.
latest_restorable = 9 * 60 + 57
interruption = 10 * 60 + 3
exposure_minutes = interruption - latest_restorable # 6
restore_minutes = 18
configuration_minutes = 7
validation_minutes = 12
sequential_recovery_minutes = restore_minutes + configuration_minutes + validation_minutes # 37Um erro de batch elimina posições às 09:50 num banco fictício. O último ponto recuperável é posterior ao erro. A equipa restaura um ponto anterior numa rede isolada, compara posições e prepara a recuperação dos movimentos legítimos seguintes antes de propor a mudança de tráfego.
Armadilhas comuns
Confundir restauro com rollback imediato; escolher o ponto mais recente após corrupção; assumir que lock protege a chave; declarar sucesso sem executar validação.
Tópicos relacionados: Failover RDS e recuperação da aplicação
A prova de recuperação combina dados históricos corretos, contexto do destino e uma aplicação funcional, dentro do objetivo acordado.
Referência: RDS point-in-time recovery · SAP-C02