1. O que é Resiliência no Azure

Resiliência na nuvem é a capacidade de um sistema continuar a funcionar — ou recuperar rapidamente — após falhas de hardware, interrupções de rede, desastres naturais ou erros humanos. No Azure, a resiliência não é um produto único: é uma camada de arquitectura que combina Availability Zones, region pairs, geo-redundância, Azure Site Recovery (ASR) e Azure Backup para garantir que as cargas de trabalho sobrevivem a falhas de qualquer magnitude.

O Azure Blog publicou em julho de 2026 o artigo “Built to bounce back: How Azure resiliency evolved”, descrevendo a evolução das capacidades de resiliência da plataforma — desde zonas físicas isoladas até recuperação automática multi-região. Para uma PME portuguesa, isto traduz-se numa questão concreta: quanto tempo pode a sua infraestrutura ficar indisponível sem parar o negócio?

2. Conceitos Fundamentais: Region Pairs, Availability Zones e Geo-redundância

Antes de configurar qualquer serviço, é obrigatório entender a hierarquia geográfica do Azure. Cada nível protege contra um tipo de falha diferente:

Region Pairs — a base da geo-redundância

O Azure emparelha regiões: North Europe ↔ West Europe, UK South ↔ UK West, France Central ↔ France South. Estes pares têm três propriedades críticas para BCDR:

• Isolamento físico: pelo menos 480 km de separação entre datacenters do par.
• Replicação automática: alguns serviços (Storage GRS, SQL Database Geo-Replication) replicam automaticamente para o par.
• Recuperação ordenada: em caso de interrupção regional, o Azure prioriza a recuperação de uma região do par de cada vez.

Availability Zones — isolamento dentro da região

Cada região do Azure que suporta Availability Zones tem um mínimo de três zonas, cada uma com datacenters independentes (energia, cooling e rede próprios). Uma VM colocada num Availability Set com fault domains não é o mesmo que uma VM num Availability Zone — as zonas são fisicamente separadas, os fault domains são racks diferentes dentro do mesmo datacenter.

3. RTO e RPO: Definir Objectivos de Recovery

Antes de implementar qualquer solução técnica, é preciso definir quanto downtime e quanta perda de dados o negócio tolera. Estes dois números determinam toda a arquitectura:

O custo da solução de BCDR é directamente proporcional a quão baixos são estes valores. Uma PME que tolera RTO=24h e RPO=1h pode usar Azure Backup simples. Se precisa de RTO=15min e RPO=0, precisa de ASR com replicação contínua — significativamente mais caro.

4. Availability Zones: Configuração Prática

Para tirar partido do SLA de 99,99% das Availability Zones, as VMs têm de ser distribuídas em pelo menos duas zonas e colocadas por trás de um Standard Load Balancer ou Application Gateway. Eis como configurar via Azure CLI e PowerShell:

Passo 1 — Criar um IP público zonal

# Azure CLI — criar IP público redundante entre zonas
az network public-ip create \
  --name myPublicIP-Zonal \
  --resource-group rg-bcdr-pme \
  --sku Standard \
  --zone 1 2 3 \
  --location northeurope

# PowerShell equivalente
az network public-ip create `
  --Name myPublicIP-Zonal `
  --ResourceGroupName rg-bcdr-pme `
  --Sku Standard `
  --Zone 1 2 3 `
  --Location northeurope

Passo 2 — Criar um Standard Load Balancer

# Criar o Load Balancer com IP frontend zonal-redundante
az network lb create \
  --name lb-bcdr-pme \
  --resource-group rg-bcdr-pme \
  --frontend-ip-name frontendIP \
  --public-ip-address myPublicIP-Zonal \
  --backend-pool-name backendPool \
  --sku Standard

Passo 3 — Criar VMs em zonas diferentes

# VM na zona 1
az vm create \
  --name vm-web-01 \
  --resource-group rg-bcdr-pme \
  --image Ubuntu2204 \
  --zone 1 \
  --vnet-name vnet-bcdr \
  --subnet subnet-web \
  --nsg-rule SSH \
  --generate-ssh-keys

# VM na zona 2
az vm create \
  --name vm-web-02 \
  --resource-group rg-bcdr-pme \
  --image Ubuntu2204 \
  --zone 2 \
  --vnet-name vnet-bcdr \
  --subnet subnet-web \
  --nsg-rule SSH \
  --generate-ssh-keys

Passo 4 — Adicionar VMs ao backend pool do Load Balancer

# Adicionar NICs ao backend pool
az network nic ip-config address-pool add \
  --address-pool backendPool \
  --lb-name lb-bcdr-pme \
  --ip-config-name ipconfig1 \
  --nic-name vm-web-01NIC \
  --resource-group rg-bcdr-pme

az network nic ip-config address-pool add \
  --address-pool backendPool \
  --lb-name lb-bcdr-pme \
  --ip-config-name ipconfig1 \
  --nic-name vm-web-02NIC \
  --resource-group rg-bcdr-pme

Passo 5 — Criar regra de health probe e load balancing

# Health probe HTTP 80
az network lb probe create \
  --name probe-http \
  --lb-name lb-bcdr-pme \
  --resource-group rg-bcdr-pme \
  --protocol Http \
  --port 80 \
  --path /

# Regra de load balancing
az network lb rule create \
  --name rule-http-80 \
  --lb-name lb-bcdr-pme \
  --resource-group rg-bcdr-pme \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name frontendIP \
  --backend-pool-name backendPool \
  --probe-name probe-http \
  --protocol Tcp \
  --idle-timeout 4

5. Azure Site Recovery (ASR): Configuração Passo a Passo

O Azure Site Recovery é o serviço de Disaster Recovery as a Service (DRaaS) do Azure. Replica VMs de uma região primária para uma região secundária e permite fazer failover orquestrado em caso de desastre. Para uma PME, é a forma mais simples de cumprir RTO<1h sem manter infraestrutura idle numa segunda região.

Passo 1 — Criar o Recovery Services Vault

# Criar o vault na região secundária (West Europe)
az resource create \
  --resource-type Microsoft.RecoveryServices/vaults \
  --name rsv-bcdr-pme \
  --resource-group rg-bcdr-pme-dr \
  --location westeurope \
  --properties '{"sku":{"name":"Standard"}}'

Passo 2 — Configurar a replicação

# Habilitar replicação de uma VM de North Europe para West Europe
az site-recovery protected-item create \
  --name vm-web-01-replication \
  --protection-container recovery-container-ne \
  --recovery-vault-name rsv-bcdr-pme \
  --resource-group rg-bcdr-pme-dr \
  --fabric-name primary-fabric \
  --policy-name replication-policy \
  --provider-details '{ \
    "providerSpecificInput": { \
      "instanceType": "A2A", \
      "vmId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", \
      "recoveryResourceGroupId": "/subscriptions/.../rg-bcdr-pme-dr", \
      "recoveryAvailabilitySetId": "/subscriptions/.../as-bcdr-pme-dr" \
    } \
  }'

Passo 3 — Definir o objectivo de ponto de recuperação (RPO)

# Criar política de replicação com RPO de 15 minutos
az site-recovery replication-policy create \
  --name replication-policy-15min \
  --vault-name rsv-bcdr-pme \
  --resource-group rg-bcdr-pme-dr \
  --provider-input '{ \
    "appConsistentFrequencyInMinutes": 15, \
    "crashConsistentFrequencyInMinutes": 5, \
    "recoveryPointRetentionInHours": 24 \
  }'

Passo 4 — Verificar estado da replicação

# Verificar estado da replicação
az site-recovery protected-item show \
  --name vm-web-01-replication \
  --protection-container recovery-container-ne \
  --recovery-vault-name rsv-bcdr-pme \
  --resource-group rg-bcdr-pme-dr \
  --fabric-name primary-fabric \
  --query "protectionStatus"

A replicação inicial pode demorar horas ou dias, dependendo do tamanho do disco. Após a replicação inicial, apenas blocos alterados são replicados (delta replication), minimizando a largura de banda consumida.

Passo 5 — Executar um failover de teste (Disaster Drill)

# Failover de teste — NÃO afecta a replicação nem a VM primária
az site-recovery recovery-plan failover-commit \
  --name rp-bcdr-pme \
  --vault-name rsv-bcdr-pme \
  --resource-group rg-bcdr-pme-dr \
  --failover-type TestFailover \
  --failover-direction PrimaryToRecovery

6. Estratégias de Backup: Azure Backup e Geo-redundância

O ASR replica VMs inteiras, mas o Azure Backup protege contra corrupção de dados, eliminações acidentais e ransomware — cenários em que replicar não ajuda (o dado corrompido é replicado para a secundária). Uma estratégia BCDR completa combina ambos.

Passo 1 — Criar um Recovery Services Vault para Backup

# Vault para backup (região primária)
az backup vault create \
  --name rsv-backup-pme \
  --resource-group rg-bcdr-pme \
  --location northeurope

Passo 2 — Configurar storage redundancy

# Configurar GRS (Geo-Redundant Storage) para backups
az backup vault backup-properties set \
  --name rsv-backup-pme \
  --resource-group rg-bcdr-pme \
  --backup-storage-redundancy GeoRedundant

Passo 3 — Habilitar backup para uma VM

# Criar política de backup: diário, retenção 30 dias
az backup policy create \
  --name policy-vm-daily-30d \
  --resource-group rg-bcdr-pme \
  --vault-name rsv-backup-pme \
  --workload-type AzureVM \
  --backup-management-type AzureIaaSVM \
  --frequency Daily \
  --retention 30

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

Passo 4 — Soft Delete e proteção contra ransomware

O Azure Backup tem Soft Delete activado por defeito: quando um backup é eliminado (mesmo por um administrador), fica em retenção durante 14 dias antes de ser permanentemente removido. Isto protege contra ransomware que tenta apagar backups antes de encriptar os dados.

# Verificar estado do soft delete
az backup vault backup-properties show \
  --name rsv-backup-pme \
  --resource-group rg-bcdr-pme \
  --query "softDeleteFeature"

# NÃO desactivar — soft delete é uma camada crítica contra ransomware

7. Planos de Recuperação e Disaster Drill

Um plano de recuperação no ASR é um documento que define a ordem em que as VMs são recuperadas, scripts de automação pós-failover e grupos de recuperação. Sem um plano, o failover é manual e caótico — exactamente o que não se quer durante um desastre.

Passo 1 — Criar um Recovery Plan

# Criar plano de recuperação (via Azure CLI preview)
az resource create \
  --resource-type Microsoft.RecoveryServices/vaults/replicationRecoveryPlans \
  --name rp-bcdr-pme \
  --resource-group rg-bcdr-pme-dr \
  --location northeurope \
  --properties '{
    "primaryFabricId": "/subscriptions/.../fabrics/primary-fabric",
    "recoveryFabricId": "/subscriptions/.../fabrics/recovery-fabric",
    "groups": [
      {
        "name": "Grupo 1 — Infraestrutura",
        "replicationProtectedItems": [
          {"id": "/subscriptions/.../replicationProtectedItems/vm-web-01"}
        ]
      },
      {
        "name": "Grupo 2 — Aplicações",
        "replicationProtectedItems": [
          {"id": "/subscriptions/.../replicationProtectedItems/vm-app-01"}
        ]
      }
    ]
  }'

Passo 2 — Adicionar scripts de automação pós-failover

# Script de automação — executado após failover da VM
# Guardar como post-failover.sh no Recovery Plan

#!/bin/bash
echo "Post-failover: actualizar DNS e verificar serviço"

# Actualizar registo DNS para apontar para a nova VM
az network dns record-set a update \
  --name app.pme.pt \
  --zone-name pme.pt \
  --resource-group rg-bcdr-pme-dr \
  --set arecords[0].ipv4Address="$(hostname -I | awk '{print $1}')"

# Verificar se o serviço responde
curl -s -o /dev/null -w "%{http_code}" http://localhost:80/health

Passo 3 — Executar e documentar o Disaster Drill

8. Custos e Considerações para PME

O BCDR no Azure não é gratuito — mas é significativamente mais barato do que manter um datacenter secundário. Eis uma estimativa de custos para uma PME típica com 5 VMs:

Compare isto com o custo de manter um datacenter físico secundário (aluguer, energia, hardware, licenças): facilmente 2.000-5.000 €/mês. O Azure reduz isto a menos de 100 €/mês para uma PME típica — mantendo o mesmo RTO e RPO.

9. Erros Comuns

10. Checklist Rápido de Verificação

Artigos Relacionados

• Azure File Sync — Sincronizar Ficheiros entre Windows Server e a Nuvem em 2026 — sincronização de ficheiros e cloud tiering no Azure
• Ransomware 2026: Como Preparar, Detectar e Recuperar (Backup 3-2-1 Imutável) — estratégia de backup imutável contra ransomware
• Zero Trust para PMEs em 2026: Como Implementar os 5 Pilares NIST com Microsoft 365 e Azure — arquitectura de segurança que complementa BCDR
• NIS2 em 2026: Como Implementar a Checklist em 90 Dias — Guia Prático para Sysadmins — requisitos de resiliência e continuidade de negócio da directiva NIS2
• NAS para PME em 2026: Synology, QNAP ou TrueNAS — Qual Escolher? — armazenamento on-premises que complementa o backup na nuvem
• Load Balancing e Escalabilidade Horizontal na Prática: Como Escalar Sistemas com NGINX — alta disponibilidade na camada de aplicação

Fonte principal: Azure Blog — “Built to bounce back: How Azure resiliency evolved” (08 Jul 2026). Documentação técnica: Microsoft Learn — Azure Reliability, Azure Site Recovery Overview, Azure Backup Overview.