APRENDER. PRATICAR. EVOLUIR.1. Recuperar uma aplicação com as suas dependências
Um recovery plan organiza máquinas e ações numa sequência de recuperação. O desenho deve partir das dependências da aplicação: identidades, DNS, base de dados, middleware, ficheiros e entrada de tráfego. Máquinas no mesmo grupo podem iniciar em paralelo; grupos diferentes permitem impor ordem. Mas uma VM em execução não prova que o seu serviço já responde ao contrato esperado. Acrescenta verificações de prontidão e ações adequadas antes de abrir o acesso a consumidores. Num caso fictício, a base arranca antes do middleware, mas os logins necessários ainda não foram validados. A sequência de arranque está correta e o serviço continua indisponível. O plano deve atribuir cada verificação a uma equipa e definir o que impede avançar para a etapa seguinte.
2. Ensaiar sem criar um segundo produtor ativo
Test failover permite exercitar uma cópia enquanto a origem continua em funcionamento. A rede de teste deve ser preparada para que a cópia não envie instruções reais, emails ou ficheiros para consumidores de produção. Isolamento de rede, DNS e dependências são parte do desenho do ensaio. No exemplo fictício, uma VM replicada contém um agendador que inicia automaticamente e credenciais de uma integração de ficheiros. Apenas arrancar a VM pode executar trabalho indesejado se o destino real estiver acessível. Define destinos simulados ou controlados, dados fictícios e testes funcionais compatíveis com esse isolamento. Regista também quais os percursos reais que ficaram fora do ensaio e precisam de validação separada. A ausência de impacto deve resultar de controlos verificados, não da esperança de que ninguém use a cópia.
3. Escolher o ponto conforme perda e tempo aceitáveis
A escolha do recovery point envolve compromissos. Um ponto já processado pode evitar trabalho adicional antes de iniciar recuperação; pedir o mais recente pode exigir processar dados que já chegaram ao serviço. Um ponto application-consistent pode ser mais antigo do que outro disponível. Não confundas o nome da opção com uma garantia universal de RPO e RTO. Compara o instante dos dados, a consistência necessária e o tempo estimado para recuperar e validar. No exercício local, os tempos são valores fictícios fornecidos pela equipa. Se nenhum candidato respeita todos os limites, a função devolve uma lista vazia. Essa é uma conclusão útil: o desenho precisa de melhoria ou de uma decisão formal sobre o compromisso, em vez de apresentar a opção menos má como cumprimento automático.
4. Distinguir retenção, soft delete e imutabilidade
Retenção define quanto tempo se pretende conservar pontos; soft delete oferece uma oportunidade de recuperar dados após eliminação; imutabilidade bloqueia operações que poderiam remover pontos protegidos. Estas capacidades não são sinónimos. Um cofre com imutabilidade ativada pode ainda ter essa configuração reversível; o estado locked torna a configuração irreversível. Antes de bloquear, a equipa deve validar impactos de políticas, custos e operações permitidas. A proteção de um cofre também não deve ser generalizada a qualquer backup operacional de blobs, ficheiros ou discos. Confirma o âmbito da funcionalidade para o tipo de backup usado. No projeto fictício, o requisito é resistir a uma eliminação maliciosa e manter recuperação utilizável. Guardar dados que ninguém consegue restaurar não satisfaz a segunda parte desse requisito.
5. Manter separação de responsabilidades na recuperação
Resource Guard acrescenta autorização para operações críticas de Azure Backup. A separação perde valor se o mesmo administrador do cofre mantiver privilégios permanentes que lhe permitam aprovar ou executar sozinho todas as operações protegidas. Define owner distinto, acesso necessário e tratamento de emergência. A lista de operações protegidas e excluídas deve ser revista para o tipo de cofre, sem assumir que todas têm a mesma predefinição. O cenário fictício exige que uma redução de retenção passe pelo controlo acordado, mas também que uma restauração urgente tenha um percurso conhecido. Testa autorização com papéis separados e documenta como obter aprovação fora de horas. O controlo deve reduzir o risco de uma identidade comprometida sem tornar a recuperação dependente de uma pessoa indisponível.
6. Encerrar o ensaio com resultados e limpeza
O ensaio termina com validação funcional, registo das lacunas e limpeza das cópias criadas. Alterações feitas numa VM de test failover não devem ser tratadas como correções automaticamente devolvidas à origem. Se o teste revelou uma configuração em falta, corrige a fonte controlada apropriada e repete o ensaio. Guarda evidência antes da limpeza: ponto usado, tempos, resultados, limitações de isolamento e tarefas abertas. A documentação de proteção de backups pode mudar por região e tipo de cofre; quando descrições oficiais divergem, regista a incerteza e valida o estado efetivo antes de aprovar o desenho. Não uses essa ambiguidade para declarar uma capacidade universal. A decisão final deve dizer o que foi demonstrado e que passos faltam para recuperar o serviço completo no contexto real.
points = [
{"id": "processed", "age": 8, "restore": 3, "app_consistent": False},
{"id": "latest", "age": 2, "restore": 8, "app_consistent": False},
{"id": "app", "age": 12, "restore": 4, "app_consistent": True},
]
def eligible(max_age, max_total, validation, require_app=False):
return [p["id"] for p in points
if p["age"] <= max_age and p["restore"] + validation <= max_total
and (not require_app or p["app_consistent"])]
assert eligible(5, 6, 2) == []
assert eligible(5, 10, 2) == ["latest"]
assert eligible(10, 6, 2) == ["processed"]
assert eligible(15, 6, 2, True) == ["app"]
assert eligible(5, 10, 2, True) == []
assert eligible(15, 6, 3, True) == []
print("six supplied recovery-point checks passed; no Azure recovery performed")
Caso fictício: o ponto mais recente cumpre o RPO, mas processá-lo e validar a aplicação excede o RTO. O ponto processado arranca mais depressa, mas é demasiado antigo. O projeto mantém a lacuna aberta e melhora o desenho.
Armadilhas comuns
Tratar VM iniciada como aplicação pronta; deixar jobs de teste falar com produção; confundir ponto mais recente com cumprimento de todos os objetivos; tratar imutabilidade ativada como locked.
Tópicos relacionados: Dependências de recuperação · RPO e RTO · Segregação de funções
Recuperação exige um ponto adequado, uma execução autorizada e evidência do serviço, com proteção e isolamento coerentes.
Referência: Test failover to Azure · AZ-305 objectives 2026-04-17