Fundamentação Teórica: Perform a Failover to a Secondary Region by Using Site Recovery
1. Intuição Inicial
No tópico anterior, você aprendeu a configurar o Azure Site Recovery: criar o vault na região de destino, habilitar replicação, definir políticas e estruturar Recovery Plans. Toda essa configuração existe para um único momento: quando você precisa acionar o failover.
O failover é o ato de ativar sua infraestrutura na região de destino. Pense no seguinte cenário: você tem um gerador de emergência instalado no prédio. Configurar o ASR é como instalar e testar o gerador. Executar o failover é como ligar o gerador quando a energia principal cai.
Mas há uma sutileza importante: existem diferentes situações que exigem diferentes tipos de failover. Ligar o gerador para um teste programado é diferente de acioná-lo durante um apagão de emergência. No ASR, essa distinção se traduz em três tipos de failover, cada um com comportamento, impacto e pré-requisitos distintos.
Na prática, o failover serve para:
- Recuperar operações quando a região primária está indisponível (emergência)
- Migrar workloads planejadamente para outra região (manutenção)
- Validar que o processo de DR funciona conforme esperado (teste)
2. Contexto
O failover é a operação mais crítica do ciclo de vida do ASR. Todo o trabalho de configuração, replicação contínua e monitoramento converge para garantir que, nesse momento, tudo funcione corretamente.
O failover não é uma operação isolada. Ele é parte de um ciclo completo que inclui o estado anterior (replicação ativa) e o estado posterior (Commit, Reprotect e Failback). Entender o ciclo completo é o que diferencia um operador que sabe executar um failover de um que sabe gerenciar o processo de DR de ponta a ponta.
3. Construção dos Conceitos
3.1 Os três tipos de failover em detalhe
Test Failover
O Test Failover cria VMs temporárias na região de destino conectadas a uma rede de teste isolada que você especifica. É completamente não destrutivo:
- A replicação continua normalmente durante e após o teste
- As VMs de produção na origem não são afetadas
- As VMs de teste são temporárias e devem ser limpas após validação
- Não muda o status de replicação do item protegido
O Test Failover é a operação mais importante do processo de DR porque é a única forma de garantir que o failover real funcionará quando necessário.
Planned Failover
O Planned Failover (também chamado de Planned Failover ou Migrate) é executado quando você sabe com antecedência que a região primária precisará ser evacuada. Características:
- Sincroniza as últimas mudanças da origem para o destino antes de criar as VMs
- RPO zero: não há perda de dados, pois todas as mudanças são sincronizadas antes do cutover
- Exige que as VMs de origem estejam desligadas no momento do failover
- Usado para manutenção planejada de região, migração definitiva ou atualizações de infraestrutura
Unplanned Failover (simplesmente "Failover")
O Failover padrão é o failover de emergência, acionado quando a região primária está indisponível ou quando uma decisão rápida é necessária. Características:
- Pode ser executado mesmo com a origem inacessível
- Usa o ponto de recuperação selecionado (pode haver perda de dados equivalente ao RPO)
- A origem não precisa estar acessível nem as VMs desligadas
- É o failover que você executará em um cenário de desastre real
3.2 Seleção do ponto de recuperação
No Failover (unplanned), você precisa escolher qual ponto de recuperação usar. As opções são:
Latest (automatically selected): usa o ponto de recuperação processado mais recentemente. Minimiza a perda de dados. É a opção padrão e recomendada para a maioria dos cenários de emergência.
Latest app-consistent: usa o ponto de recuperação consistente com aplicação mais recente. Pode ser mais antigo que o "Latest", mas garante consistência para bancos de dados e aplicações transacionais.
Latest crash-consistent: usa o ponto crash-consistent mais recente. Mais rápido de processar.
Custom: permite selecionar manualmente um ponto específico. Útil quando você sabe que os dados foram corrompidos após um determinado momento e quer restaurar para um estado anterior específico.
3.3 O processo de Commit
Após o failover (planned ou unplanned), as VMs estão rodando na região de destino, mas o ASR ainda mantém a associação com o ponto de recuperação original. O Commit finaliza o failover:
- Marca o failover como permanente
- Descarta os pontos de recuperação antigos associados à origem
- Libera o item para entrar no processo de Reprotect
Sem o Commit, você pode cancelar o failover e retornar ao estado anterior (se a origem ainda estiver acessível). Após o Commit, isso não é mais possível.
3.4 Reprotect e Failback
Após o Commit, as VMs estão rodando na região de destino mas sem proteção ativa. Para restabelecer a proteção e possibilitar o retorno à região de origem, você executa o Reprotect.
O Reprotect inverte a direção da replicação: a região de destino vira a nova origem, e a região de origem (quando se recuperar) vira o novo destino. Após o Reprotect estar ativo e a sincronização concluída, você pode executar o Failback para retornar as VMs para a região original.
4. Visão Estrutural
5. Funcionamento na Prática
Fluxo completo de um failover de emergência
Fase 1: Detecção e decisão
A região primária (ex: Brazil South) apresenta degradação severa. Você verifica no portal do Azure que a região está com problemas e decide acionar o failover.
Fase 2: Acesso ao vault
Como o vault está na região de destino (ex: East US 2), ele está acessível mesmo com a origem com problemas. Acesse o vault pela URL do portal ou via PowerShell/CLI.
Fase 3: Execução do failover
- No vault, acesse Site Recovery > Replicated Items
- Selecione a VM ou execute via Recovery Plan (recomendado para múltiplas VMs)
- Clique em Failover
- Selecione o ponto de recuperação
- Marque a opção "Shut down machine before beginning failover" apenas se a origem ainda estiver acessível. Se a origem estiver inacessível, desmarque.
- Confirme
Fase 4: Monitoramento
O failover cria as VMs na região de destino. O processo inclui:
- Criação dos discos gerenciados a partir das réplicas
- Provisionamento da VM com o tamanho e configurações pré-definidos
- Inicialização do sistema operacional
O tempo típico de failover para uma VM Azure é de 15 a 30 minutos, dependendo do tamanho dos discos e das configurações.
Fase 5: Validação pós-failover
Antes do Commit, verifique:
- VM iniciou corretamente
- Serviços críticos estão rodando
- Conectividade de rede está funcionando
- Dados críticos estão íntegros
Fase 6: Commit
Após validação positiva, execute o Commit para finalizar o failover. Se a validação falhar, você ainda pode cancelar o failover e retornar ao estado anterior (somente se a origem ainda estiver acessível).
Comportamentos pouco óbvios
O failover não atualiza DNS automaticamente: após o failover, as VMs estão rodando na região de destino com IPs diferentes. O DNS, Load Balancer e qualquer outro serviço de roteamento ainda apontam para a origem. Você precisa atualizar manualmente (ou via automação) para redirecionar o tráfego para as VMs de destino.
"Shut down machine before beginning failover" não é obrigatório: esta opção tenta desligar a VM de origem antes de iniciar o failover para garantir consistência. Se a origem estiver inacessível, desmarcar é necessário. Se a origem estiver acessível, marcar reduz a possibilidade de split-brain (duas instâncias do mesmo sistema rodando simultaneamente).
O failover pode ser cancelado antes do Commit: enquanto o Commit não for executado, o failover pode ser revertido. Após o Commit, o processo é irreversível para aquele ciclo.
Após o Commit, a VM de origem não é automaticamente excluída: a VM na região de origem (se ainda existir) permanece no estado em que estava. Você precisa gerenciar o descomissionamento manualmente.
O Test Failover cria recursos que geram custo: as VMs criadas pelo Test Failover consomem custo até serem limpas. Se você executar um Test Failover e esquecer de limpar, continuará sendo cobrado.
6. Formas de Implementação
6.1 Portal Azure
Quando usar: failovers de emergência onde a velocidade e a familiaridade visual são críticas; situações onde operadores menos técnicos precisam executar o processo.
Executando Test Failover no portal:
- Acesse o vault na região de destino
- Site Recovery > Replicated Items
- Selecione o item > clique em Test Failover
- Selecione:
- Recovery Point: Latest (recomendado)
- Azure virtual network: selecione a rede de teste isolada
- Clique em OK
- Monitore em Jobs
- Após validação, clique em Cleanup test failover
- Adicione notas sobre o resultado do teste e confirme a limpeza
Executando Failover (unplanned) no portal:
- Acesse o vault na região de destino
- Site Recovery > Replicated Items
- Selecione o item > clique em Failover
- Leia e confirme o aviso de impacto
- Selecione o ponto de recuperação
- Configure "Shut down machines before beginning failover" conforme o cenário
- Clique em OK
- Monitore o job até conclusão
- Valide as VMs na região de destino
- Clique em Commit para finalizar
6.2 Azure PowerShell
Quando usar: automação de failover em pipelines de DR, failover de múltiplos itens em sequência, integração com runbooks.
Test Failover via PowerShell:
# Configurar contexto do vault
$vault = Get-AzRecoveryServicesVault `
-ResourceGroupName "rg-asr-eastus2" `
-Name "rsv-asr-eastus2"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
# Obter o item replicado
$replicationItem = Get-AzRecoveryServicesAsrReplicationProtectedItem `
-ProtectionContainer (Get-AzRecoveryServicesAsrProtectionContainer `
-Fabric (Get-AzRecoveryServicesAsrFabric -Name "asr-a2a-default-brazilsouth-container")) `
-Name "replication-vm-producao-01"
# Executar Test Failover
$testFailoverJob = Start-AzRecoveryServicesAsrTestFailoverJob `
-ReplicationProtectedItem $replicationItem `
-Direction PrimaryToRecovery `
-AzureVMNetworkId "/subscriptions/{sub}/resourceGroups/rg-asr/providers/Microsoft.Network/virtualNetworks/vnet-teste-isolado"
# Aguardar conclusão
$testFailoverJob | Wait-AzRecoveryServicesAsrJob
Write-Output "Test Failover concluido. Status: $($testFailoverJob.State)"
# Limpar Test Failover após validação
$cleanupJob = Start-AzRecoveryServicesAsrTestFailoverCleanupJob `
-ReplicationProtectedItem $replicationItem `
-Comment "Teste DR Q1 2025 - Validado com sucesso"
$cleanupJob | Wait-AzRecoveryServicesAsrJob
Failover (unplanned) via PowerShell:
# Executar Failover com ponto de recuperação mais recente
$failoverJob = Start-AzRecoveryServicesAsrUnplannedFailoverJob `
-ReplicationProtectedItem $replicationItem `
-Direction PrimaryToRecovery `
-PerformSourceSideAction $false # false se origem inacessível
# Aguardar conclusão
$failoverJob | Wait-AzRecoveryServicesAsrJob
Write-Output "Failover concluido. Status: $($failoverJob.State)"
# Após validação, executar Commit
$commitJob = Start-AzRecoveryServicesAsrCommitFailoverJob `
-ReplicationProtectedItem $replicationItem
$commitJob | Wait-AzRecoveryServicesAsrJob
Write-Output "Commit concluido"
Reprotect após failover:
# Após o Commit, iniciar Reprotect (inverte direção de replicação)
$reprotectJob = Update-AzRecoveryServicesAsrProtectionDirection `
-ReplicationProtectedItem $replicationItem `
-Direction RecoveryToPrimary `
-FailoverDeploymentModel ResourceManager
$reprotectJob | Wait-AzRecoveryServicesAsrJob
Write-Output "Reprotect iniciado"
6.3 Azure CLI
Quando usar: verificações de status e operações simples em scripts bash.
# Listar itens replicados com status
az site-recovery replication-protected-item list \
--resource-group rg-asr-eastus2 \
--vault-name rsv-asr-eastus2 \
--fabric-name asr-a2a-default-brazilsouth-container \
--protection-container-name asr-a2a-default-brazilsouth-container \
--output table
# Verificar jobs em andamento
az site-recovery job list \
--resource-group rg-asr-eastus2 \
--vault-name rsv-asr-eastus2 \
--filter "status eq 'InProgress'" \
--output table
Para operações complexas como failover com parâmetros específicos, o PowerShell é mais completo e recomendado. A CLI do ASR tem cobertura menor de funcionalidades avançadas.
6.4 Recovery Plans via Portal
Para múltiplas VMs, o Recovery Plan é o método recomendado. No portal:
Executando failover via Recovery Plan:
- Vault > Site Recovery > Recovery Plans
- Selecione o Recovery Plan
- Clique em Failover
- Selecione o ponto de recuperação (Latest recomendado)
- O plan executa os grupos em sequência, respeitando a ordem configurada
- Monitore cada grupo em Jobs
- Após conclusão e validação, execute Commit no Recovery Plan inteiro
Vantagem crítica: o Recovery Plan garante que o banco de dados inicie antes dos servidores de aplicação, que iniciam antes dos servidores web. Sem isso, servidores de aplicação podem tentar se conectar a um banco que ainda não está disponível, causando falhas em cascata.
7. Controle e Segurança
RBAC para operações de failover
| Operação | Role mínima |
|---|---|
| Executar Test Failover | Site Recovery Operator |
| Executar Failover (unplanned) | Site Recovery Operator |
| Executar Planned Failover | Site Recovery Operator |
| Executar Commit | Site Recovery Operator |
| Executar Reprotect | Site Recovery Contributor |
| Executar Failback | Site Recovery Operator |
| Criar/modificar Recovery Plans | Site Recovery Contributor |
Proteção contra failover acidental
Para evitar que um failover seja executado por engano em produção, considere:
- Locks no vault: um
CanNotDeletelock não impede operações de failover, mas umReadOnlylock impede qualquer modificação, incluindo failover. Use com cuidado; locks ReadOnly em vaults de ASR podem impedir operações de DR em emergência. - Multi-User Authorization (MUA): configure o Resource Guard para exigir aprovação de um segundo administrador antes de operações críticas como failover
- Alertas de auditoria: configure Azure Monitor para alertar sobre qualquer operação de failover iniciada
Consistência de dados no failover
Ao selecionar o ponto de recuperação, considere o tipo de workload:
| Workload | Ponto recomendado | Motivo |
|---|---|---|
| Servidor web estático | Latest (crash-consistent) | Stateless; qualquer ponto é aceitável |
| Banco de dados SQL | Latest app-consistent | Necessita consistência transacional |
| Servidor de arquivos | Latest | Arquivos podem ser verificados após restore |
| Aplicação com fila de mensagens | Latest app-consistent | Estado da fila precisa ser consistente |
8. Tomada de Decisão
Qual tipo de failover usar
| Situação | Tipo de Failover | Motivo |
|---|---|---|
| Validação trimestral de DR | Test Failover | Não afeta produção; permite validação completa |
| Manutenção programada de região | Planned Failover | RPO zero; desliga VMs de origem antes |
| Região primária inacessível por desastre | Unplanned Failover | Origem inacessível; urgência máxima |
| Migração definitiva para outra região | Planned Failover | Controlado, sem perda de dados |
| Suspeita de corrupção de dados recente | Custom Recovery Point | Permite selecionar ponto anterior à corrupção |
Failover individual vs Recovery Plan
| Cenário | Abordagem | Motivo |
|---|---|---|
| VM única independente | Failover individual | Mais simples; sem dependências |
| Stack de aplicação com dependências | Recovery Plan | Garante ordem de inicialização |
| Múltiplas VMs sem dependências entre si | Failover individual em paralelo | Mais rápido que Recovery Plan sequencial |
| Ambiente completo de produção | Recovery Plan | Orquestração, ações automáticas e auditoria |
Commit imediato vs validação antes do Commit
| Situação | Abordagem | Motivo |
|---|---|---|
| Emergência crítica, sem tempo para validação | Commit imediato após failover | Libera replicação reversa o quanto antes |
| Failover planejado com janela de manutenção | Validar extensivamente antes do Commit | Possibilidade de cancelar se algo falhar |
| Test Failover (não chega ao Commit) | Limpeza sem Commit | Test Failover não usa Commit |
9. Boas Práticas
Documentar o runbook de DR: crie um documento passo a passo para o failover, incluindo contatos de aprovação, sequência de ações, critérios de validação e procedimentos de rollback. Em uma emergência, ninguém deve precisar improvisar.
Medir e registrar o RTO real: execute Test Failovers cronometrados e registre o tempo total de cada etapa (criação das VMs, inicialização dos serviços, validação, atualização de DNS). Use esses dados para comunicar o RTO real ao negócio.
Atualizar DNS como parte do failover: configure o processo de atualização de DNS (via Traffic Manager, Azure Front Door ou registro manual) como uma etapa explícita no Recovery Plan ou no runbook. DNS não atualizado é uma das causas mais comuns de RTO inflado.
Nunca usar a mesma rede de produção no Test Failover: sempre especifique uma rede de teste isolada (sem roteamento para produção) para evitar conflitos de IP e comunicação acidental com sistemas de produção.
Executar Reprotect imediatamente após o Commit: após um failover de emergência, a nova região de destino fica sem proteção de DR. Execute o Reprotect o mais rápido possível para restabelecer a resiliência.
Validar o Recovery Plan a cada mudança de infraestrutura: sempre que uma nova VM for adicionada ao ambiente ou a topologia de rede for alterada, revise e atualize os Recovery Plans.
10. Erros Comuns
Erro: executar Test Failover na rede de produção Por que acontece: o operador seleciona a VNet de produção por conveniência, sem perceber o impacto. Como evitar: crie uma VNet dedicada para testes de DR, sem peering com produção, e use-a exclusivamente para Test Failovers.
Erro: esquecer de limpar o Test Failover Por que acontece: o teste é executado, validado e o operador segue para outras tarefas sem limpar. Como evitar: inclua a limpeza no runbook de teste como etapa obrigatória. Configure alertas para VMs com tag de teste que estejam rodando há mais de 24 horas.
Erro: não atualizar DNS após o failover Por que acontece: o operador considera o failover concluído quando as VMs estão rodando, sem perceber que o tráfego ainda está indo para a origem. Como evitar: inclua atualização de DNS como etapa explícita no runbook e/ou no Recovery Plan com ação automatizada.
Erro: fazer Commit antes de validar as VMs Por que acontece: pressão por velocidade em situações de emergência. Como evitar: mesmo em emergências, uma validação básica (VM iniciou? Serviço principal responde?) leva menos de 5 minutos e pode poupar horas de retrabalho se algo estiver errado.
Erro: não executar Reprotect após o failover Por que acontece: o operador está focado em restabelecer o serviço e não pensa na proteção do novo estado. Como evitar: inclua Reprotect como a última etapa obrigatória do runbook de DR. Após um failover, você não tem DR até o Reprotect estar ativo.
Erro: selecionar ponto de recuperação errado Por que acontece: em situações de emergência, o operador aceita o padrão sem avaliar o cenário. Como evitar: para workloads transacionais, prefira sempre o ponto app-consistent. Para cenários de corrupção de dados, avalie o Custom para selecionar um ponto anterior à corrupção.
11. Operação e Manutenção
Monitoramento pós-failover
Após um failover, o monitoramento muda de perspectiva. Você passa a monitorar as VMs na região de destino como se fossem o novo ambiente de produção:
| O que monitorar | Onde verificar | Frequência |
|---|---|---|
| Status do Reprotect após failover | Site Recovery > Replicated Items | A cada hora até Protected |
| RPO após Reprotect | Replicated Items > RPO | Contínuo |
| Saúde das VMs na nova região | Azure Monitor / VM Insights | Contínuo |
| Jobs do ASR com falha | Site Recovery > Jobs | Diário |
| Alertas de replicação | Azure Monitor Alerts | Imediato |
Processo de Failback detalhado
O Failback é o retorno para a região de origem após o Reprotect estar ativo. O processo é idêntico ao failover, mas na direção inversa:
- Verificar que o Reprotect está em estado Protected e o RPO está saudável
- Executar um Planned Failover (RecoveryToPrimary) para retornar sem perda de dados
- Aguardar a criação das VMs na região de origem
- Validar funcionamento na origem
- Executar Commit
- Executar Reprotect novamente (agora reestabelecendo a replicação origem→destino)
- Verificar que o estado voltou ao normal com replicação ativa
Limites operacionais relevantes para failover
| Limite | Valor |
|---|---|
| Tempo máximo entre Test Failover consecutivos | Sem limite formal |
| Número máximo de VMs em um Recovery Plan | 100 VMs por plano |
| Número de grupos em um Recovery Plan | 3 grupos padrão; extensível com Automation |
| Tempo de retenção de pontos de recuperação | 15 dias |
| Número de ações de script por Recovery Plan | Sem limite documentado |
12. Integração e Automação
Recovery Plan com Azure Automation Runbook
O Recovery Plan pode executar Azure Automation Runbooks como etapas entre grupos de VMs. Isso permite automatizar ações como:
- Atualizar registros DNS no Azure DNS ou Traffic Manager
- Escalar recursos de rede (ex: aumentar capacidade do gateway VPN)
- Notificar equipes via Microsoft Teams ou email
- Executar scripts de validação de serviços
Integração com Azure Monitor para failover automático
Para cenários de DR totalmente automatizado (sem intervenção humana), é possível criar um fluxo que detecta a falha da região e aciona o failover automaticamente:
- Azure Monitor detecta métricas críticas de falha regional
- Action Group aciona um Logic App ou Automation Runbook
- O Runbook executa o failover via PowerShell (conforme código demonstrado anteriormente)
- O Runbook atualiza DNS e notifica a equipe após conclusão
Atenção: failover totalmente automático sem aprovação humana é adequado apenas para workloads onde o RTO é tão crítico que qualquer atraso humano é inaceitável. Para a maioria dos cenários, uma aprovação humana mínima é recomendada para evitar failovers desnecessários por falsos positivos.
13. Resumo Final
O que é: processo de ativar a infraestrutura replicada na região de destino quando a região de origem falha ou é evacuada planejadamente, com três modalidades distintas de execução.
Pontos essenciais:
- Existem três tipos de failover: Test (não destrutivo, rede isolada), Planned (RPO zero, VMs desligadas na origem) e Unplanned (emergência, pode haver perda de dados)
- O Commit finaliza o failover e é obrigatório antes do Reprotect; após o Commit, o failover não pode ser revertido
- O Reprotect inverte a direção da replicação e é necessário para habilitar o Failback
- O Test Failover usa uma rede isolada e deve ser limpo após validação
- O failover não atualiza DNS automaticamente; essa etapa deve ser planejada explicitamente
- Recovery Plans garantem ordem de inicialização e permitem ações automáticas entre grupos
Diferenças críticas entre os tipos de failover:
| Aspecto | Test Failover | Planned Failover | Unplanned Failover |
|---|---|---|---|
| Impacto na produção | Nenhum | VMs de origem desligadas | Depende do cenário |
| Perda de dados | Nenhuma | Zero (sincroniza antes) | Equivalente ao RPO |
| Origem precisa estar acessível | Não | Sim | Não |
| Requer Commit | Não (usa limpeza) | Sim | Sim |
| Uso típico | Testes de DR | Manutenção planejada | Desastre real |
| Replicação durante a operação | Continua normalmente | Pausa para sincronização | Para após execução |
O que precisa ser lembrado para o AZ-104:
- Test Failover não afeta produção e não requer Commit; usa limpeza após validação
- Planned Failover requer VMs de origem desligadas e garante RPO zero
- Após Commit, o Reprotect inverte a direção: destino passa a replicar para origem
- DNS não é atualizado automaticamente pelo ASR; planeje essa etapa
- Recovery Plans permitem orquestrar failover de múltiplas VMs com ordem e automação
- O vault do ASR deve estar na região de destino (reforço do conceito anterior)