Resiliência e BCDR em Azure: Availability Zones e Recovery para PME

UmaVM única em Azure não é “alta disponibilidade” — é uma VM numa rack que pode falhar. Quando uma zona inteira cai (e caiu em 2023, 2024 e 2025 em várias regiões Azure), a sua aplicação fica offline se não tiver resiliência configurada. Este artigo mostra, para uma PME com 3-5 VMs críticas e uma base de dados, como configurar Availability Zones, geo-redundância de storage, Azure Site Recovery para disaster recovery e Azure Backup com Recovery Services Vault — com custos reais e uma checklist BCDR pronta a usar. Tudo baseado em documentação oficial Microsoft Learn e na página de redundância de storage do Azure.

Conceitos de Resiliência Azure: SLA por Tier

O Azure oferece vários níveis de resiliência, cada um com um SLA (Service Level Agreement) diferente. Compreender estes níveis é o primeiro passo para escolher a estratégia certa — e não pagar mais do que o necessário. A documentação do Azure Well-Architected Framework define resiliência como a capacidade de um sistema recuperar de falhas e continuar a funcionar.

Existem quatro níveis principais de resiliência em Azure, do mais básico ao mais robusto:

O salto de 99,9% para 99,99% parece pequeno, mas representa uma diferença enorme em tempo de inatividade anual: passa de 8h 45min para 52 min de downtime tolerado por ano. Para uma PME onde uma hora offline pode custar milhares de euros, esse salto justifica-se. A página de disponibilidade de VMs no Microsoft Learn detalha cada opção.

Availability Zones: Zona-Redundant vs Zone-Aligned

Availability Zones são datacenters fisicamente separados dentro de uma mesma região Azure, com energia, refrigeração e networking independentes. Cada região suporta no mínimo 3 zonas. A documentação oficial de Availability Zones explica a arquitectura completa.

Existem duas formas de usar Availability Zones, e a diferença é crítica:

Zone-Aligned (ou Zonal): O recurso é colocado numa zona específica (ex: Zona 1). Se essa zona falhar, o recurso fica indisponível. Usa-se quando precisa de baixa latência entre componentes que devem estar na mesma zona, ou quando o serviço não suporta redundância automática entre zonas.

Zone-Redundant (ou Zonal-Redundant): O recurso replica automaticamente entre 3 zonas. Se uma zona falhar, o serviço continua sem interrupção. Suportado por serviços como Standard Load Balancer, Application Gateway v2, Azure SQL Database (tiers Premium/Business Critical), e Managed Disks com ZRS (Zone-Redundant Storage).

Para VMs, a estratégia típica é colocar 2 ou mais VMs em zonas diferentes (zone-aligned por VM), com um Standard Load Balancer zone-redundant à frente. Os discos podem ser LRS (locally redundant, dentro da zona) ou ZRS (replicados entre zonas). A lista de serviços que suportam Availability Zones no Microsoft Learn é actualizada regularmente.

Para criar uma VM numa zona específica via Azure CLI:

az vm create \
  --resource-group rg-pme-prod \
  --name vm-app-01 \
  --image UbuntuLTS \
  --size Standard_D4s_v5 \
  --zone 1 \
  --vnet-name vnet-prod \
  --subnet subnet-app \
  --public-ip-sku Standard \
  --os-disk-storage-account-type Premium_ZRS

E a segunda VM na Zona 2, com o mesmo disco ZRS:

az vm create \
  --resource-group rg-pme-prod \
  --name vm-app-02 \
  --image UbuntuLTS \
  --size Standard_D4s_v5 \
  --zone 2 \
  --vnet-name vnet-prod \
  --subnet subnet-app \
  --public-ip-sku Standard \
  --os-disk-storage-account-type Premium_ZRS

O parâmetro --os-disk-storage-account-type Premium_ZRS replica o disco entre as 3 zonas, garantindo que se uma zona cair, a VM na outra zona pode arrancar com um disco consistente. Mais detalhes na documentação de redundância de Managed Disks.

Geo-Redundância: GRS, RA-GRS, GZRS

Availability Zones protegem contra falhas de datacenter dentro de uma região. Mas se a região inteira cair (evento raro mas já aconteceu — ver incidentes de South Central US 2018, East US 2 2023), precisa de geo-redundância: os dados replicados para uma região secundária a centenas de quilómetros de distância. A documentação de redundância de Azure Storage define quatro opções principais:

A diferença entre GRS e GZRS é que GZRS combina redundância zonal (3 zonas na região primária) com replicação geográfica (1 região secundária). É a opção mais robusta — sobrevive a falha de zona E falha de região. A página de GRS no Microsoft Learn detalha o processo de replicação assíncrona.

Para alterar a opção de redundância de uma storage account via CLI:

az storage account create \
  --name stpmeprod001 \
  --resource-group rg-pme-prod \
  --sku Standard_GZRS \
  --kind StorageV2 \
  --enable-large-file-shares true

Para verificar a região secundária emparelhada:

az storage account show \
  --name stpmeprod001 \
  --resource-group rg-pme-prod \
  --query "[geoReplicationStats, secondaryLocation]" \
  --output table

Azure Site Recovery (ASR) para DR

Azure Site Recovery (ASR) é o serviço de Disaster Recovery do Azure. Replica VMs de uma região primária para uma região secundária e, em caso de desastre, permite fazer failover com poucos cliques. Ao contrário da geo-replicação de storage (que replica apenas dados), o ASR replica a VM inteira — SO, discos, configuração. A documentação oficial do ASR descreve a arquitectura completa.

O ASR funciona de forma simples conceitualmente:

1. Replicação contínua: Os discos da VM primária são replicados assincronamente para a região secundária. O RPO típico é de 30 segundos a 15 minutos, dependendo da taxa de escrita.
2. Recovery Services Vault: Um vault na região secundária armazena os metadados de replicação e orquestra o failover.
3. Failover de teste: Pode simular um failover sem afectar a produção — cria VMs temporárias na região secundária para validar que tudo funciona.
4. Failover real: Em caso de desastre, inicia o failover. As VMs são criadas na região secundária com os últimos dados replicados. RTO típico: 10-30 minutos.
5. Re-protect e failback: Após a região primária recuperar, pode re-proteger (inverter a replicação) e fazer failback.

A arquitectura Azure-to-Azure do ASR usa uma rede virtual separada na região secundária, com o mesmo espaço de endereçamento (ou sobreposto), para que as VMs mantenham os mesmos IPs após failover.

Para habilitar replicação ASR para uma VM via CLI:

# 1. Criar o Recovery Services Vault na região secundária
az recovery-services vault create \
  --name rsv-pme-dr \
  --resource-group rg-pme-dr \
  --location "West Europe"

# 2. Habilitar replicação da VM para a região secundária
az site-recovery protected-vm create \
  --name vm-app-01-protection \
  --vault-name rsv-pme-dr \
  --resource-group rg-pme-dr \
  --fabric-name primary-fabric \
  --protection-container primary-container \
  --protected-item-name vm-app-01 \
  --recovery-vault-resource-group rg-pme-dr \
  --recovery-location "West Europe" \
  --recovery-vnet-name vnet-dr \
  --recovery-subnet subnet-app-dr \
  --source-vm-id /subscriptions/SUB_ID/resourceGroups/rg-pme-prod/providers/Microsoft.Compute/virtualMachines/vm-app-01

Para verificar o estado de replicação e o RPO actual:

az site-recovery protected-vm show \
  --name vm-app-01-protection \
  --vault-name rsv-pme-dr \
  --resource-group rg-pme-dr \
  --query "[properties.protectionState, properties.rpoInSeconds]" \
  --output table

Para executar um failover de teste (não afecta produção):

az site-recovery recovery-plan test-failover \
  --name rp-pme-critical \
  --vault-name rsv-pme-dr \
  --resource-group rg-pme-dr \
  --recovery-point Latest \
  --vnet-name vnet-test-dr

Azure Backup: Recovery Services Vault

Azure Backup é diferente do ASR. O ASR replica VMs para DR regional; o Azure Backup cria pontos de restauro periódicos (snapshots + transferência para cofre) para recuperar de corrupção de dados, eliminações acidentais ou ransomware. A documentação do Azure Backup explica a diferença detalhadamente.

O componente central é o Recovery Services Vault (RSV), um cofre que armazena os backups de VMs, SQL Server, ficheiros e outros recursos. O RSV oferece:

• Backup de VMs Azure: Snapshots consistentes com a aplicação (via VSS no Windows ou scripts pre/post no Linux) armazenados no cofre.
• Retenção configurável: Diário, semanal, mensal, anual — com retenção até 9999 anos (para compliance).
• Soft delete: Por defeito, backups eliminados são retidos 14 dias antes de eliminação permanente — protege contra ransomware que tenta apagar backups.
• Immutability (WORM): Bloqueia backups contra eliminação mesmo pelo administrador — essencial contra ransomware.
• Restauro granular: Pode restaurar ficheiros individuais, discos ou VMs completas.

Para habilitar backup de uma VM via CLI:

# 1. Criar Recovery Services Vault
az backup vault create \
  --name rsv-pme-backup \
  --resource-group rg-pme-backup \
  --location "North Europe"

# 2. Configurar política de backup (diário, retenção 30 dias)
az backup policy create \
  --workload-type VM \
  --backup-management-type AzureIaaSVM \
  --name policy-vm-daily-30d \
  --vault-name rsv-pme-backup \
  --resource-group rg-pme-backup \
  --backup-frequency-type Daily \
  --backup-frequency-count 1 \
  --backup-times "02:00" \
  --retention-type Daily \
  --retention-count 30

# 3. Habilitar backup na VM
az backup protection enable-for-vm \
  --vault-name rsv-pme-backup \
  --resource-group rg-pme-backup \
  --vm vm-app-01 \
  --vm-resource-group rg-pme-prod \
  --policy-name policy-vm-daily-30d

Para verificar os pontos de restauro disponíveis:

az backup recoverypoint list \
  --vault-name rsv-pme-backup \
  --resource-group rg-pme-backup \
  --container-name iaasvmcontainerv2;rg-pme-prod;vm-app-01 \
  --item-name vm;rg-pme-prod;vm-app-01 \
  --query "[].{Time:recoveryPointTime,Type:recoveryPointType}" \
  --output table

Para restaurar uma VM completa a partir de um ponto de restauro, ver a documentação de restauro de VMs. O restauro cria uma nova VM ou pode substituir a existente.

RTO/RPO: Como Escolher a Estratégia

RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar o serviço após uma falha. RPO (Recovery Point Objective) é a quantidade máxima de dados que se pode perder (medida em tempo). Estes dois valores definem toda a estratégia BCDR. A documentação do Well-Architected Framework explica como definir estes valores.

A escolha depende de dois factores: quanto custa cada hora offline (RTO) e quanto custa perder X horas de dados (RPO). Para uma PME típica, a combinação mais custo-eficiente é:

• RTO 30 min, RPO 15 min: Availability Zones (protecção zona) + ASR (protecção regional). Custo moderado.
• RTO 4 horas, RPO 1 hora: Azure Backup diário + GRS. Custo baixo.
• RTO 15 min, RPO < 1 min: Multi-região activo-activo com SQL geo-replication + Application Gateway multi-região. Custo elevado.

Exemplo Prático PME: VMs Críticas + BD + Storage

Vamos aplicar tudo isto a um cenário real: uma PME com 50 funcionários, um ERP interno (Dynamics NAV / PHC / ERP próprio), uma base de dados SQL Server, e um file server. Os requisitos: RTO 30 min, RPO 15 min. Região primária: North Europe. Região secundária: West Europe.

A arquitectura recomendada:

O script completo para criar esta infraestrutura (resumo — substituir SUB_ID, nomes de recursos conforme necessário):

#!/bin/bash
# BCDR Setup PME — North Europe (primary) + West Europe (DR)
RG_PROD="rg-pme-prod"
RG_DR="rg-pme-dr"
RG_BACKUP="rg-pme-backup"
LOC_PRIMARY="northeurope"
LOC_DR="westeurope"

# --- Resource Groups ---
az group create --name $RG_PROD --location $LOC_PRIMARY
az group create --name $RG_DR --location $LOC_DR
az group create --name $RG_BACKUP --location $LOC_PRIMARY

# --- VNet Primary ---
az network vnet create --resource-group $RG_PROD --name vnet-prod \
  --address-prefix 10.10.0.0/16 --subnet-name subnet-app \
  --subnet-prefix 10.10.1.0/24

# --- VNet DR ---
az network vnet create --resource-group $RG_DR --name vnet-dr \
  --address-prefix 10.10.0.0/16 --subnet-name subnet-app-dr \
  --subnet-prefix 10.10.1.0/24

# --- VMs em Availability Zones ---
for i in 1 2; do
  az vm create --resource-group $RG_PROD --name vm-app-0$i \
    --image UbuntuLTS --size Standard_D4s_v5 \
    --zone $i --vnet-name vnet-prod --subnet subnet-app \
    --public-ip-sku Standard --os-disk-storage-account-type Premium_ZRS \
    --no-wait
done

# --- Azure SQL Database (zone-redundant, Premium) ---
az sql server create --name sql-pme-prod --resource-group $RG_PROD \
  --location $LOC_PRIMARY --admin-user sqladmin --admin-password "STRONG_PASS!"
az sql db create --server sql-pme-prod --name db-erp \
  --resource-group $RG_PROD --edition Premium --zone-redundant true

# --- Failover Group SQL (primary -> DR) ---
az sql server create --name sql-pme-dr --resource-group $RG_DR \
  --location $LOC_DR --admin-user sqladmin --admin-password "STRONG_PASS!"
az sql failover-group create --name fog-erp \
  --server sql-pme-prod --partner-server sql-pme-dr \
  --resource-group $RG_PROD --partner-resource-group $RG_DR \
  --failover-policy Automatic --grace-period 60

# --- Azure Files (GZRS) ---
az storage account create --name stpmeprod001 \
  --resource-group $RG_PROD --sku Premium_GZRS \
  --kind FileStorage --location $LOC_PRIMARY

# --- Recovery Services Vault (Backup) ---
az backup vault create --name rsv-pme-backup \
  --resource-group $RG_BACKUP --location $LOC_PRIMARY

# --- ASR Vault (DR) ---
az recovery-services vault create --name rsv-pme-dr \
  --resource-group $RG_DR --location $LOC_DR

Após executar, falta habilitar a replicação ASR para cada VM e configurar a política de backup (ver secções anteriores). O SQL Failover Group garante que a base de dados faz failover automaticamente para West Europe se North Europe ficar indisponível — sem intervenção manual.

Custos de Resiliência

Resiliência tem custo. Para uma PME, é importante perceber o custo marginal de cada camada. Os valores abaixo são estimativas para a região North Europe, baseados na calculadora de preços do Azure (preços de 2026, podem variar).

O custo de resiliência é aproximadamente 52% acima do custo base. Para uma PME, os 215 EUR/mês adicionais compram: tolerância a falha de zona (99,99% SLA), DR regional com RTO 20 min, backups imutáveis anti-ransomware, e geo-replicação de storage. Compare-se com o custo de 4-8 horas offline (perda de produtividade de 50 funcionários, perda de vendas, penalizações contratuais) — o ROI é claro.

Para optimizar custos, ver o artigo Azure IaaS: Optimizar Custos Cloud para PMEs em 2026 — onde Reserved Instances, Spot VMs e Azure Advisor podem reduzir a factura em 30-50%.

Erros Comuns

BCDR Checklist

Checklist prática para implementar e manter BCDR numa PME em Azure:

Planeamento

• ✓ Definir RTO/RPO por aplicação crítica (website, ERP, BD, file server)
• ✓ Identificar região secundária emparelhada com a primária (ex: North Europe ↔ West Europe)
• ✓ Documentar dependências entre aplicações, bases de dados e storage
• ✓ Verificar suporte de Availability Zones na região escolhida

Implementação

• ✓ VMs críticas em 2+ Availability Zones com discos Premium_ZRS
• ✓ Standard Load Balancer zone-redundant à frente das VMs
• ✓ SQL Database em tier Premium/Business Critical com zone-redundant + failover group
• ✓ Storage accounts com GZRS ou RA-GZRS para dados críticos
• ✓ Azure Backup habilitado em todas as VMs com retenção mínima 30 dias
• ✓ Soft delete + immutability activados no Recovery Services Vault
• ✓ ASR habilitado para VMs críticas com recovery plan configurado
• ✓ VNet-DR criada com subnets matching antes de precisar de failover

Validação Contínua

• ✓ Fazer failover de teste ASR trimestralmente (não afecta produção)
• ✓ Restaurar um backup mensalmente para validar integridade
• ✓ Verificar RPO do ASR via az site-recovery protected-vm show
• ✓ Monitorizar alertas do Recovery Services Vault no Azure Monitor
• ✓ Revisão trimestral de custos com Azure Advisor e Azure Cost Management
• ✓ Documentar runbook de failover com passos manuais e contactos

Artigos Relacionados

• Azure IaaS: Optimizar Custos Cloud para PMEs em 2026 — como reduzir a factura Azure com Reserved Instances, Spot VMs e Azure Advisor
• Azure Monitor: Monitorização Cloud para PMEs em 2026 — configurar alertas para eventos de resiliência (falhas de zona, backups falhados, RPO elevado)
• Azure VPN Gateway Site-to-Site 2026 — conectividade híbrida entre on-premise e Azure (essencial para DR de infraestruturas mistas)
• CSPM para PMEs: Cloud Security Posture Management no Azure com Microsoft Defender for Cloud — validar configuração de resiliência e segurança
• Gestão de Chaves Externas no Azure Managed HSM: BYOK e Integração com PKI On-Premise — protecção de chaves de encriptação para backups e discos