Fundamentação Teórica: Configure Azure Site Recovery for Azure Resources
1. Intuição Inicial
Nos tópicos anteriores, você aprendeu a proteger dados com Azure Backup: criar vaults, políticas e executar backups e restores. O Backup resolve o problema de perda de dados (alguém excluiu um arquivo, um disco corrompeu, um banco de dados foi alterado acidentalmente).
O Azure Site Recovery (ASR) resolve um problema diferente e mais grave: e se a região inteira do Azure ficar indisponível? Um terremoto, uma falha catastrófica de datacenter, uma interrupção prolongada de energia. Nesse cenário, não adianta ter backups na mesma região, pois o vault também estaria inacessível.
A analogia: o Azure Backup é como um cofre dentro do seu escritório onde você guarda cópias de documentos. O Azure Site Recovery é como ter um escritório completo e operacional em outra cidade, pronto para funcionar imediatamente se sua sede principal for destruída. Não é só sobre dados; é sobre toda a infraestrutura em execução.
O ASR replica continuamente suas VMs para uma região secundária. Se a região primária falhar, você executa um failover e suas VMs sobem na região secundária em minutos. Quando a região primária se recuperar, você executa um failback para retornar ao estado original.
2. Contexto
O ASR é a componente de BCDR (Business Continuity and Disaster Recovery) do Azure. Enquanto o Backup foca em RPO e retenção de dados, o ASR foca em:
- RTO (Recovery Time Objective): quanto tempo para a infraestrutura estar operacional após um desastre
- RPO (Recovery Point Objective): quanto de perda de dados é aceitável (no ASR, o RPO para VMs Azure é de aproximadamente 60 segundos)
O ASR existe dentro do Recovery Services Vault (não no Backup Vault). Isso é importante: você usa o mesmo vault tanto para Azure Backup quanto para ASR, mas são funcionalidades separadas dentro dele.
O ASR para recursos Azure (VM para VM, região para região) é diferente do ASR para recursos on-premises. O foco deste tópico é exclusivamente Azure VM para Azure VM (Azure-to-Azure replication), que é o cenário exigido no AZ-104.
3. Construção dos Conceitos
3.1 Terminologia fundamental
Antes de avançar, você precisa dominar os termos específicos do ASR.
Região de origem (Source Region): onde suas VMs estão rodando normalmente. Exemplo: Brazil South.
Região de destino (Target Region): onde as VMs serão replicadas e para onde o failover ocorrerá. Exemplo: East US 2.
Replicação: processo contínuo de copiar as mudanças de disco da VM de origem para a região de destino. É incremental e acontece em background sem impactar a VM.
Cache Storage Account: conta de armazenamento criada automaticamente na região de origem. As mudanças de disco são enviadas primeiro para esse cache antes de serem transferidas para a região de destino. Atua como buffer para garantir que nenhuma mudança seja perdida.
Recovery Point: ponto no tempo capturado durante a replicação. Existem dois tipos:
- Crash-consistent: capturado automaticamente a cada 5 minutos. Equivale ao estado da VM como se tivesse sido desligada abruptamente. Adequado para a maioria dos workloads.
- App-consistent: capturado com frequência configurável (padrão: a cada 4 horas). Usa VSS para garantir consistência de aplicações (bancos de dados, serviços). Mais seguro para workloads transacionais.
Failover: processo de ativar as VMs replicadas na região de destino. Pode ser:
- Test Failover: cria VMs na região de destino em uma rede isolada, sem afetar a replicação ou a produção. Para testes de DR.
- Planned Failover: failover controlado, sem perda de dados. Usado para manutenção planejada de região.
- Unplanned Failover (Failover): acionado quando a região primária falha. Pode haver perda de dados equivalente ao RPO.
Failback: processo de retornar as operações para a região de origem após um failover, quando a região primária se recupera.
Reprotect: após um failover, as VMs estão rodando na região de destino. Para habilitar failback, você deve "reproteger" as VMs, invertendo a direção da replicação (destino vira origem temporária).
3.2 Recovery Plans
Um Recovery Plan é uma sequência orquestrada de failover para múltiplas VMs. Em vez de executar failover individualmente em cada VM, você cria um plano que:
- Define a ordem de inicialização das VMs (bancos de dados antes de servidores de aplicação)
- Agrupa VMs que devem iniciar simultaneamente
- Inclui ações manuais (ex: notificar a equipe) ou scripts automatizados entre etapas
3.3 Recursos criados automaticamente na região de destino
Quando você habilita a replicação de uma VM, o ASR cria automaticamente (ou permite que você configure) os seguintes recursos na região de destino:
| Recurso | Comportamento padrão | Configurável |
|---|---|---|
| Resource Group | Cria novo com sufixo "-asr" | Sim |
| Virtual Network | Cria nova mapeada da origem | Sim (Network Mapping) |
| Subnet | Replica estrutura de subnets | Sim |
| Storage Account (cache) | Cria na origem para cache | Parcialmente |
| Managed Disks | Cria discos replicados no destino | Sim (tipo de disco) |
| VM (réplica) | Criada apenas no failover | Sim (tamanho, configurações) |
| Availability Set / Zones | Configura no destino | Sim |
3.4 Network Mapping
O Network Mapping é a configuração que define como as redes virtuais da região de origem se mapeiam para redes na região de destino. Isso garante que, após o failover, as VMs na região de destino se conectem às redes corretas.
Sem Network Mapping, as VMs de failover são conectadas a uma rede padrão genérica. Com Network Mapping, você garante conectividade correta com outros recursos, VPNs e ExpressRoutes na região de destino.
4. Visão Estrutural
5. Funcionamento na Prática
Ciclo de vida completo do ASR
Etapas detalhadas para habilitar replicação
1. Pré-requisito: criar o Recovery Services Vault na região de destino
Este é um ponto crítico e frequentemente confundido: o vault para ASR deve estar na região de DESTINO, não na origem. A lógica é que, se a região de origem falhar, o vault na origem também estaria indisponível. O vault na região de destino permanece acessível para orquestrar o failover.
# O vault DEVE estar na região de destino
az recovery-services vault create \
--resource-group rg-asr-eastus2 \
--name rsv-asr-eastus2 \
--location eastus2
2. Habilitar replicação para uma VM
No portal:
- Acesse o Recovery Services Vault (na região de destino)
- Clique em "Site Recovery" > "Enable replication"
- Configure:
- Source: Azure, região de origem, Resource Group e VM
- Target: região, Resource Group, VNet, subnet, tipo de disco
- Replication settings: política de replicação
- Confirme e aguarde a sincronização inicial
A sincronização inicial pode levar horas dependendo do tamanho dos discos. Durante esse período, o status é "Enabling replication" e depois "Synchronizing".
3. Verificar saúde da replicação
Após a sincronização inicial, o status passa para Protected. Monitore:
- RPO: quanto tempo desde o último ponto de recuperação. Deve estar próximo de 0-60 segundos
- Replication health: Critical, Warning ou Healthy
- Last recovery point: o ponto de recuperação mais recente disponível
Test Failover: como e quando executar
O Test Failover cria VMs na região de destino em uma rede isolada especificada por você, sem interromper a replicação e sem afetar a produção. É a operação de DR mais importante para validar que o ASR está configurado corretamente.
Comportamentos importantes do Test Failover:
- As VMs criadas no test failover não são a réplica de produção; são VMs temporárias criadas especificamente para o teste
- A replicação continua normalmente durante o test failover
- Você deve limpar o test failover após a validação, o que remove as VMs de teste e libera os recursos temporários
- Se você não limpar, as VMs de teste permanecem consumindo custo
Failover: sequência de eventos
O Commit é uma etapa crítica: após validar que as VMs na região de destino estão funcionando, você confirma o failover com Commit. Isso encerra a possibilidade de retornar ao ponto de recuperação anterior e prepara o ambiente para o processo de Reprotect/Failback.
6. Formas de Implementação
6.1 Portal Azure
Quando usar: configuração inicial, operações de failover/failback em situações de emergência onde a familiaridade com o portal é essencial.
Habilitando replicação no portal:
- Acesse o vault na região de destino
- Em Site Recovery, clique em "Enable replication"
- Preencha Source: "Azure", região de origem, Resource Group, VM
- Preencha Target: região destino, Resource Group, VNet, subnet, storage
- Configure Replication Policy
- Revise e habilite
Limitação: não escalável para muitas VMs; use PowerShell ou CLI para habilitar replicação em lote.
6.2 Azure PowerShell
Quando usar: habilitar replicação em múltiplas VMs, automação, pipelines de infraestrutura.
# Definir contexto do vault (região de destino)
$vault = Get-AzRecoveryServicesVault `
-ResourceGroupName "rg-asr-eastus2" `
-Name "rsv-asr-eastus2"
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
# Obter fabric da região de origem (criado automaticamente quando o vault detecta a origem)
$primaryFabric = Get-AzRecoveryServicesAsrFabric `
-Name "asr-a2a-default-brazilsouth-container"
# Obter Protection Container da origem
$primaryContainer = Get-AzRecoveryServicesAsrProtectionContainer `
-Fabric $primaryFabric
# Obter política de replicação
$replicationPolicy = Get-AzRecoveryServicesAsrPolicy `
-Name "24-hour-retention-policy"
# Obter container de destino
$recoveryFabric = Get-AzRecoveryServicesAsrFabric `
-Name "asr-a2a-default-eastus2-container"
$recoveryContainer = Get-AzRecoveryServicesAsrProtectionContainer `
-Fabric $recoveryFabric
# Associar containers com a política
$containerMapping = Get-AzRecoveryServicesAsrProtectionContainerMapping `
-ProtectionContainer $primaryContainer `
-Name "mapping-brazilsouth-to-eastus2"
# Obter a VM a replicar
$vm = Get-AzVM `
-ResourceGroupName "rg-app-prod" `
-Name "vm-producao-01"
# Configurar detalhes do disco para replicação
$diskConfig = New-AzRecoveryServicesAsrAzureToAzureDiskReplicationConfig `
-ManagedDisk `
-LogStorageAccountId "/subscriptions/.../storageAccounts/cacheaccount" `
-DiskId $vm.StorageProfile.OsDisk.ManagedDisk.Id `
-RecoveryResourceGroupId "/subscriptions/.../resourceGroups/rg-asr-eastus2" `
-RecoveryReplicaDiskAccountType "Premium_LRS" `
-RecoveryTargetDiskAccountType "Premium_LRS"
# Habilitar replicação
New-AzRecoveryServicesAsrReplicationProtectedItem `
-AzureToAzure `
-AzureVmId $vm.Id `
-Name "replication-vm-producao-01" `
-ProtectionContainerMapping $containerMapping `
-AzureToAzureDiskReplicationConfiguration $diskConfig `
-RecoveryResourceGroupId "/subscriptions/.../resourceGroups/rg-asr-eastus2" `
-RecoveryVirtualNetworkId "/subscriptions/.../virtualNetworks/vnet-destino"
6.3 Azure CLI
Quando usar: scripts de automação, pipelines simples, verificações de status.
# Listar itens replicados
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 saúde de replicação de um item
az site-recovery replication-protected-item show \
--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 \
--replicated-protected-item-name replication-vm-producao-01
A CLI do ASR é menos completa que o PowerShell para operações complexas como habilitar replicação com configurações detalhadas de disco. Para operações de failover e monitoramento, a CLI é suficiente.
6.4 ARM Template / Terraform
Quando usar: IaC para infraestrutura completa de DR, ambientes onde toda a configuração precisa ser versionada.
A configuração do ASR via ARM/Terraform é complexa porque envolve múltiplos recursos interdependentes (fabrics, containers, mappings, protected items). Para o AZ-104, o conhecimento de portal e PowerShell é suficiente. Em ambientes de produção reais, o Terraform tem providers para ASR via azurerm_site_recovery_replication_policy e azurerm_site_recovery_protected_vm.
7. Controle e Segurança
RBAC para ASR
| Role | Capacidades |
|---|---|
| Site Recovery Contributor | Gerenciar ASR completamente, exceto criar vaults |
| Site Recovery Operator | Executar failover e failback; não pode modificar configurações |
| Site Recovery Reader | Somente leitura do status de replicação |
Considerações de rede para replicação
O ASR precisa de conectividade de saída da VM de origem para os endpoints do ASR e do Azure Storage. Em ambientes com Network Security Groups (NSGs) restritos ou User Defined Routes (UDRs) forçando tráfego por firewall, você precisa:
- Permitir tráfego de saída para Service Tags
AzureSiteRecoveryeStoragenos NSGs - Ou configurar Private Endpoints para o vault, eliminando tráfego pela internet pública
- Verificar se proxies ou firewalls não estão bloqueando os endpoints necessários
Replication Policy: configurações de segurança
A Replication Policy define:
- Recovery Point Retention: por quanto tempo os pontos de recuperação são mantidos (padrão: 24 horas, máximo: 15 dias)
- App-consistent snapshot frequency: frequência dos snapshots consistentes com aplicação (padrão: 4 horas)
- Multi-VM consistency: permite que VMs em um grupo sejam failover juntas com o mesmo ponto de recuperação (desabilitado por padrão; habilitar causa leve impacto em performance)
8. Tomada de Decisão
ASR vs Backup: quando usar cada um
| Situação | Solução | Motivo |
|---|---|---|
| Arquivo excluído acidentalmente | Azure Backup | ASR não protege dados individuais |
| Banco de dados corrompido por query errada | Azure Backup | Precisa restaurar para um ponto anterior |
| Região primária inteira indisponível | Azure Site Recovery | Backup na mesma região também estaria indisponível |
| RTO < 30 minutos para VM crítica | Azure Site Recovery | Backup tem RTO de horas; ASR tem RTO de minutos |
| RPO < 1 hora | Azure Site Recovery | Backup daily tem RPO de 24h; ASR tem RPO de ~60s |
| Manutenção planejada de região | Azure Site Recovery | Planned Failover sem perda de dados |
| Conformidade com retenção de 7 anos | Azure Backup | ASR não mantém histórico; só o estado atual |
Atenção: ASR e Backup não são mutuamente exclusivos. Para workloads críticos, use os dois: ASR para garantir continuidade operacional em desastres regionais e Backup para proteção contra perda ou corrupção de dados.
Onde criar o vault para ASR
| Cenário | Localização do vault | Motivo |
|---|---|---|
| ASR para VMs Azure (A2A) | Região de DESTINO | Vault acessível mesmo se origem falhar |
| Backup de VMs Azure | Mesma região da VM | Vault próximo dos dados protegidos |
9. Boas Práticas
Vault na região de destino, sempre: o vault do ASR deve estar na região de destino. Esta é a regra mais importante e mais confundida do ASR.
Executar Test Failover regularmente: pelo menos uma vez por trimestre para cada item crítico. Um failover nunca testado é um failover de confiabilidade desconhecida. Documente o RTO real medido nos testes.
Separar VMs críticas em Recovery Plans: não execute failover manualmente VM por VM em situação de crise. Recovery Plans garantem ordem de inicialização e reduzem erros humanos sob pressão.
Configurar Network Mapping: sem isso, as VMs de failover podem não se conectar às redes corretas, exigindo reconfiguração manual durante um desastre, aumentando o RTO.
Monitorar RPO continuamente: um RPO que cresce gradualmente indica problema de replicação. Configure alertas quando o RPO exceder 60 minutos, por exemplo.
Considerar Multi-VM Consistency apenas quando necessário: habilitar Multi-VM Consistency adiciona overhead de replicação. Use apenas para VMs que genuinamente precisam de consistência entre si (ex: cluster de banco de dados).
Dimensionar a conta de armazenamento de cache adequadamente: a cache storage account precisa de capacidade suficiente para absorver picos de escrita da VM de origem. Use Standard_LRS como tipo de conta de cache.
10. Erros Comuns
Erro: criar o vault na região de origem Por que acontece: o operador cria o vault onde estão suas VMs, por analogia com o Azure Backup. Como evitar: memorize a regra: vault do ASR na região de DESTINO. Sempre.
Erro: nunca executar Test Failover Por que acontece: Test Failover parece opcional e cria trabalho extra (limpeza após o teste). Como evitar: inclua Test Failover no calendário de manutenção. Sem teste, você não tem garantia de que o failover funcionará quando mais precisar.
Erro: esquecer de fazer Commit após failover bem-sucedido Por que acontece: o operador faz failover, valida as VMs, e esquece de commitar. Como evitar: inclua o Commit como etapa obrigatória no runbook de DR. Sem Commit, o failover não está finalizado e o Reprotect não pode ser iniciado.
Erro: tentar usar ASR para backup de longo prazo Por que acontece: confundir recuperação de desastres com backup de dados. Como evitar: lembre que ASR mantém apenas 15 dias de pontos de recuperação. Para retenção longa, use Azure Backup. Use ambos em conjunto para proteção completa.
Erro: não configurar Network Mapping Por que acontece: é uma configuração adicional que parece opcional no fluxo de habilitação. Como evitar: configure Network Mapping imediatamente após criar o vault. Sem isso, o failover pode criar VMs sem conectividade de rede adequada.
Erro: habilitar Multi-VM Consistency para todas as VMs por padrão Por que acontece: o operador pensa que mais consistência é sempre melhor. Como evitar: Multi-VM Consistency só deve ser habilitado para VMs de um mesmo cluster ou que compartilham dependência de dados em tempo real. Para VMs independentes, o overhead não justifica.
11. Operação e Manutenção
Monitoramento diário
No portal, acesse o vault e vá para Site Recovery. Verifique:
- Replicated Items: status de cada VM replicada (Healthy, Warning, Critical)
- Recovery Plans: integridade dos planos de DR
- Jobs: falhas nas últimas 24h
- RPO: tempo desde o último ponto de recuperação para cada VM crítica
Estados de saúde da replicação
| Estado | Significado | Ação necessária |
|---|---|---|
| Healthy | Replicação funcionando; RPO dentro do esperado | Nenhuma |
| Warning | Problema leve; RPO levemente elevado ou evento pontual | Investigar, mas não crítico |
| Critical | Replicação interrompida ou RPO muito elevado | Ação imediata necessária |
| Synchronizing | Sincronização inicial ou re-sync em andamento | Aguardar conclusão |
Limites importantes do ASR para Azure VMs
| Limite | Valor |
|---|---|
| VMs protegidas por vault | 5000 |
| Discos por VM replicada | Até 100 discos |
| Tamanho máximo de disco replicado | 32 TB |
| Retenção de pontos de recuperação | Até 15 dias |
| RPO mínimo garantido | ~60 segundos |
| Throughput máximo de replicação por VM | Sem limite fixo; limitado pela rede e disco |
12. Integração e Automação
Integração com Azure Automation para DR automatizado
O padrão mais avançado é integrar Recovery Plans com Azure Automation Runbooks para criar um processo de failover totalmente automatizado:
Integração com Azure Traffic Manager / Front Door
Após um failover, as VMs estão na região de destino, mas o DNS e o balanceamento de carga ainda podem estar apontando para a região de origem. Integre ASR com:
- Azure Traffic Manager: configure com prioridade ou failover automático para redirecionar tráfego para a região de destino após um failover
- Azure Front Door: oferece failover global automático baseado em health probes
Execução de failover via PowerShell em Recovery Plan
# Obter o Recovery Plan
$rp = Get-AzRecoveryServicesAsrRecoveryPlan `
-Name "rp-producao-completo" `
-Vault $vault
# Executar Test Failover
$job = Start-AzRecoveryServicesAsrTestFailoverJob `
-RecoveryPlan $rp `
-Direction PrimaryToRecovery `
-AzureVMNetworkId "/subscriptions/.../virtualNetworks/vnet-teste-isolado"
# Aguardar conclusão
Get-AzRecoveryServicesAsrJob -Job $job | Wait-AzRecoveryServicesAsrJob
# Limpar Test Failover
Start-AzRecoveryServicesAsrTestFailoverCleanupJob `
-RecoveryPlan $rp `
-Comment "Teste de DR trimestral concluido com sucesso"
13. Resumo Final
O que é: Azure Site Recovery é o serviço de recuperação de desastres do Azure que replica continuamente VMs de uma região de origem para uma região de destino, permitindo failover em minutos com RPO de aproximadamente 60 segundos.
Pontos essenciais:
- O vault do ASR deve estar na região de destino, não na origem
- O RPO do ASR para VMs Azure é de aproximadamente 60 segundos (crash-consistent a cada 5 min, app-consistent configurável)
- Existem três tipos de failover: Test (não destrutivo, rede isolada), Planned (sem perda de dados) e Unplanned (emergência)
- Após o failover, é obrigatório fazer Commit antes de iniciar o Reprotect para failback
- Recovery Plans orquestram failover de múltiplas VMs com ordem de inicialização e ações automatizadas
- ASR e Azure Backup são complementares, não alternativos; use os dois para workloads críticos
Diferenças críticas:
| Aspecto | Azure Backup | Azure Site Recovery |
|---|---|---|
| Objetivo | Proteção de dados | Continuidade operacional |
| RPO | Horas a dias | ~60 segundos |
| RTO | Horas | Minutos |
| Retenção | Até 99 anos | Até 15 dias |
| Localização do vault | Mesma região da VM | Região de DESTINO |
| Recurso de teste | Restore em sandbox | Test Failover (sem impacto) |
| Escopo de proteção | Arquivos, VMs, bancos | VMs inteiras |
O que precisa ser lembrado para o AZ-104:
- Vault do ASR sempre na região de destino
- Test Failover não afeta produção e não interrompe replicação
- Commit é obrigatório após failover para liberar Reprotect
- Recovery Plans definem ordem de inicialização e agrupam VMs
- Multi-VM Consistency adiciona overhead; use apenas quando necessário
- Network Mapping garante conectividade correta das VMs após failover
- ASR não substitui Backup: use ambos em conjunto para proteção completa