APRENDER. PRATICAR. EVOLUIR.Começar pela falha que o negócio precisa de suportar
Distingue indisponibilidade do componente, perda de uma região e erro lógico nos dados. Uma réplica pode ajudar a retomar numa falha regional e já conter a eliminação indevida que se pretende desfazer. Antes de escolher mecanismo, define qual estado válido precisa de ser recuperado e quanto trabalho pode ser perdido. Nomeia os responsáveis pela decisão de failover e pela aceitação de reconciliação. No contexto de fundos, a retoma técnica pode ocorrer antes de o fecho estar validado; o relatório deve tornar essa diferença visível.
Dar ao cliente o listener e a consistência certos
Num failover group, usa o contrato de listener adequado ao tipo de trabalho. A aplicação de escrita deve acompanhar o primário atual e tratar reconexão; um hostname físico fixo pode continuar a apontar ao destino anterior. Um relatório isolado que aceita atraso pode usar a geo-secondary. Uma confirmação imediata de transferência não deve inferir falha só porque a réplica ainda mostra o saldo antigo. Define no desenho quais consultas precisam de refletir a escrita recente e quais toleram atraso, para evitar que uma otimização de leitura altere a semântica do negócio.
Preparar dependências que não estão nas tabelas
A existência dos dados no secundário não garante que a aplicação consegue entrar. Se há utilizadores mapeados a logins do master, prepara e valida esses objetos no destino. Utilizadores contidos podem reduzir essa dependência, mas não eliminam DNS, rede ou controlos da aplicação. Inclui alertas que devem passar a observar o novo primário. Faz o ensaio com a identidade operacional real ou com uma identidade de teste equivalente e aprovada. Um administrador conseguir executar SELECT não demonstra que o serviço retomou para os consumidores previstos.
Medir RTO e RPO com pressupostos explícitos
No modelo, deteção leva quatro minutos e decisão três. Dados e rede arrancam depois em paralelo, demorando doze e oito; a validação final leva cinco. O total é 4+3+max(12,8)+5=24 minutos. Se as equipas não conseguem trabalhar em paralelo, o cálculo muda. Para RPO, um ponto confirmado sete minutos antes do incidente não demonstra um objetivo de cinco. Um grace period de uma hora também não sustenta, por si, RTO de vinte minutos. Documenta o que é medido, estimado ou ainda depende de autorização.
Restaurar sem apagar a possibilidade de reconciliar
PITR cria uma base separada; planeia a sua validação e o destino da aplicação. No incidente das 15:20, o ponto das 15:19 pode recuperar linhas apagadas e excluir movimentos válidos posteriores. Preserva evidência do estado atual e compara por identidades de negócio antes de decidir substituição ou correção seletiva. Não repitas efeitos externos apenas porque faltam numa cópia antiga. Define quem aceita o saldo reconciliado e como documentar exceções. A operação de restore é uma parte do procedimento, não uma decisão automática sobre quais movimentos são válidos.
Aceitar retoma, atraso e failback separadamente
O serviço pode voltar a aceitar pedidos e ainda ter backlog. Se chegam cem trabalhos por minuto e concluem cento e sessenta, a capacidade líquida é sessenta; 1800 pendentes exigem trinta minutos com taxas constantes. Mede esse atraso separadamente da recuperação inicial. Confirma capacidade e monitorização na região de retoma e evita failback precipitado só porque a região antiga voltou. O regresso deve ter critérios de sincronização, responsabilidade e ensaio apropriados. Estas contas são modelos de planeamento, sem demonstrar tempos reais de uma subscrição Azure.
A promoção SQL acaba em nove minutos, mas falta um login e o alerta observa a região antiga. O ensaio continua até provar a operação útil e o acesso do RUN.
Armadilhas comuns
Usar réplica como backup histórico; confundir read-only com consistência imediata; ignorar logins externos à base; excluir deteção ou validação do prazo.
Tópicos relacionados: RTO, RPO e capacidade · Consistência e reconciliação
Recuperar significa voltar a produzir o resultado acordado com dados aceitáveis, acesso funcional e operação observável.
Referência: Disaster recovery architecture · AZ-305 objectives 2026-04-17