Laboratório Hands-on Guiado: AZ-104 Microsoft Azure Administrator

Cenário

A Contoso Farma, distribuidora farmacêutica com sede em São Paulo, opera um sistema de gestão de pedidos e um portal B2B hospedados em máquinas virtuais no Azure. O ambiente atual consiste em duas VMs na região Brazil South (uma rodando Windows Server 2022 com IIS para o portal web e outra com SQL Server para o banco de dados), ambas dentro de uma VNet com duas sub-redes. A empresa ainda não possui nenhuma estratégia de backup nem plano de recuperação de desastres.

Após uma auditoria de conformidade, a diretoria de TI determinou que todos os workloads críticos devem possuir backup automatizado com retenção mínima de 30 dias, restauração testada e validada, e capacidade de failover para uma região secundária (East US 2) com RTO inferior a 1 hora. Sua missão como administrador Azure é implementar toda essa estratégia de proteção utilizando Azure Backup e Azure Site Recovery, configurar políticas, executar operações de backup e restauração, realizar failover para a região secundária e configurar relatórios e alertas para monitoramento contínuo.

Pré-requisitos

Antes de iniciar a Fase 1, crie ou confirme a existência dos seguintes recursos. Todos os nomes devem ser usados exatamente como indicado para manter a consistência ao longo do laboratório.

1. Resource Group

Crie o grupo de recursos principal que conterá todos os recursos do lab.

Via Portal

Acesse o portal Azure em portal.azure.com
Navegue até Resource groups > Clique em Create
Preencha Subscription com sua assinatura ativa
Preencha Resource group com rg-contosofarma-lab
Selecione Region como Brazil South
Clique em Review + create > Clique em Create

Via CLI

az group create \
  --name rg-contosofarma-lab \
  --location brazilsouth

2. Virtual Network e Sub-redes

Crie a VNet com duas sub-redes para hospedar as VMs.

Via Portal

Navegue até Virtual networks > Clique em Create
Preencha Resource group com rg-contosofarma-lab
Preencha Name com vnet-contosofarma
Selecione Region como Brazil South
Na aba IP addresses, configure o espaço de endereçamento como 10.0.0.0/16
Adicione a sub-rede snet-web com intervalo 10.0.1.0/24
Adicione a sub-rede snet-data com intervalo 10.0.2.0/24
Clique em Review + create > Clique em Create

Via CLI

az network vnet create \
  --resource-group rg-contosofarma-lab \
  --name vnet-contosofarma \
  --address-prefix 10.0.0.0/16 \
  --location brazilsouth

az network vnet subnet create \
  --resource-group rg-contosofarma-lab \
  --vnet-name vnet-contosofarma \
  --name snet-web \
  --address-prefix 10.0.1.0/24

az network vnet subnet create \
  --resource-group rg-contosofarma-lab \
  --vnet-name vnet-contosofarma \
  --name snet-data \
  --address-prefix 10.0.2.0/24

3. Máquina Virtual Windows (Portal Web)

Via Portal

Navegue até Virtual machines > Clique em Create > Azure virtual machine
Preencha Resource group com rg-contosofarma-lab
Preencha Virtual machine name com vm-web-01
Selecione Region como Brazil South
Selecione Image como Windows Server 2022 Datacenter: Azure Edition
Selecione Size como Standard_B2s
Preencha Username com azureadmin e defina uma senha segura
Na aba Networking, selecione vnet-contosofarma e sub-rede snet-web
Clique em Review + create > Clique em Create

Via CLI

az vm create \
  --resource-group rg-contosofarma-lab \
  --name vm-web-01 \
  --image Win2022Datacenter \
  --size Standard_B2s \
  --vnet-name vnet-contosofarma \
  --subnet snet-web \
  --admin-username azureadmin \
  --admin-password 'SuaSenhaSegura123!' \
  --location brazilsouth

4. Máquina Virtual Windows (Banco de Dados)

Repita o processo acima com os seguintes valores diferentes:

Virtual machine name: vm-sql-01
Sub-rede: snet-data
Demais configurações idênticas à VM anterior

Via CLI

az vm create \
  --resource-group rg-contosofarma-lab \
  --name vm-sql-01 \
  --image Win2022Datacenter \
  --size Standard_B2s \
  --vnet-name vnet-contosofarma \
  --subnet snet-data \
  --admin-username azureadmin \
  --admin-password 'SuaSenhaSegura123!' \
  --location brazilsouth

5. Storage Account para diagnósticos

Via CLI

az storage account create \
  --resource-group rg-contosofarma-lab \
  --name stcontosofarmadiag \
  --location brazilsouth \
  --sku Standard_LRS

6. Log Analytics Workspace

Necessário para relatórios do Azure Backup na Fase 4.

Via CLI

az monitor log-analytics workspace create \
  --resource-group rg-contosofarma-lab \
  --workspace-name law-contosofarma \
  --location brazilsouth

Tabela de Referência de Recursos

Recurso	Nome no lab	Região
Resource Group	rg-contosofarma-lab	Brazil South
Virtual Network	vnet-contosofarma	Brazil South
Sub-rede Web	snet-web (10.0.1.0/24)	Brazil South
Sub-rede Data	snet-data (10.0.2.0/24)	Brazil South
VM Portal Web	vm-web-01	Brazil South
VM Banco de Dados	vm-sql-01	Brazil South
Storage Account	stcontosofarmadiag	Brazil South
Log Analytics Workspace	law-contosofarma	Brazil South
Recovery Services Vault	rsv-contosofarma	Brazil South
Backup Vault	bv-contosofarma	Brazil South
Backup Policy VM	policy-vm-diario	Brazil South
Backup Policy Blob	policy-blob-semanal	Brazil South
Recovery Services Vault (DR)	rsv-contosofarma-dr	East US 2
Resource Group (DR)	rg-contosofarma-dr	East US 2

Fases do Laboratório

O laboratório está organizado em quatro fases progressivas. Cada fase constrói sobre os recursos da anterior, partindo da criação da infraestrutura de cofres até o monitoramento contínuo da solução completa.

Fase 1 — Criação dos Cofres de Backup

Nesta fase, você criará o Recovery Services vault e o Azure Backup vault, que são os pilares da estratégia de proteção. O Recovery Services vault será usado para backup de VMs e para o Site Recovery nas fases seguintes. O Backup vault será usado para proteger os blobs do Storage Account. Ambos serão criados no Resource Group rg-contosofarma-lab da fase de pré-requisitos. Também será criado o Resource Group da região secundária para o cenário de disaster recovery.

Tarefa 1.1 — Criar o Recovery Services Vault

O Recovery Services vault é o contêiner central que armazenará os pontos de recuperação das VMs e também servirá como base para o Azure Site Recovery. Nesta tarefa, você criará o vault na região Brazil South e verificará suas configurações padrão de redundância de armazenamento.

Via Portal

Navegue até o portal Azure > pesquise Recovery Services vaults na barra de busca
Clique em Create
Selecione Subscription com sua assinatura
Selecione Resource group como rg-contosofarma-lab
Preencha Vault name com rsv-contosofarma
Selecione Region como Brazil South
Clique em Review + create > Clique em Create
Após a criação, navegue até o vault rsv-contosofarma
Navegue até Properties (no menu lateral esquerdo)
Em Backup Configuration, clique em Update
Confirme que Storage replication type está configurado como Geo-redundant (padrão)
Verifique se a opção Cross Region Restore está disponível e habilite-a selecionando Enable
Clique em Save

Via CLI

# Criar o Recovery Services vault
az backup vault create \
  --resource-group rg-contosofarma-lab \
  --name rsv-contosofarma \
  --location brazilsouth

# Verificar a configuração de redundância do vault
az backup vault backup-properties show \
  --resource-group rg-contosofarma-lab \
  --name rsv-contosofarma \
  --query storageModelType

# O valor padrão deve ser "GeoRedundant"
# Para alterar (se necessário): 
# az backup vault backup-properties set \
#   --resource-group rg-contosofarma-lab \
#   --name rsv-contosofarma \
#   --backup-storage-redundancy GeoRedundant

# Habilitar Cross Region Restore
az backup vault backup-properties set \
  --resource-group rg-contosofarma-lab \
  --name rsv-contosofarma \
  --cross-region-restore-flag true

A criação do vault com redundância geográfica e Cross Region Restore habilitado garante que os dados de backup sejam replicados para a região pareada (East US 2), permitindo restaurações mesmo em caso de indisponibilidade regional completa.

Tarefa 1.2 — Criar o Azure Backup Vault

Diferente do Recovery Services vault, o Azure Backup vault é o recurso mais recente projetado para fontes de dados como Blobs do Azure Storage, discos gerenciados e servidores de banco de dados. Nesta tarefa, você criará o Backup vault e verificará suas propriedades de imutabilidade.

Via Portal

Navegue até o portal Azure > pesquise Backup vaults na barra de busca (note que é diferente de "Recovery Services vaults")
Clique em Create
Selecione Subscription com sua assinatura
Selecione Resource group como rg-contosofarma-lab
Preencha Backup vault name com bv-contosofarma
Selecione Region como Brazil South
Em Redundancy, selecione Locally-redundant
Clique em Review + create > Clique em Create
Após a criação, navegue até o vault bv-contosofarma
Navegue até Properties no menu lateral
Em Immutability, observe que a configuração padrão é Disabled
Clique em o lápis de edição ao lado de Immutability
Marque a caixa Enable immutability e clique em Save

Via CLI

# Criar o Backup vault
az dataprotection backup-vault create \
  --resource-group rg-contosofarma-lab \
  --vault-name bv-contosofarma \
  --location brazilsouth \
  --storage-settings datastore-type="VaultStore" type="LocallyRedundant"

# Verificar as propriedades do vault criado
az dataprotection backup-vault show \
  --resource-group rg-contosofarma-lab \
  --vault-name bv-contosofarma \
  --query "{Name:name, Location:location, Redundancy:properties.storageSettings[0].type}"

O Backup vault foi criado com redundância local, adequado para o armazenamento de blobs que já possuem seus próprios mecanismos de redundância no Storage Account. A imutabilidade habilitada protege os backups contra exclusão acidental ou por ransomware.

Tarefa 1.3 — Validar a diferença de estado entre os cofres e tratar erro de configuração

Antes de prosseguir para a configuração de políticas, é essencial confirmar que ambos os cofres foram criados corretamente e entender a diferença entre eles. Nesta tarefa, você também simulará um cenário de erro comum: tentar alterar a redundância de armazenamento do Recovery Services vault após a proteção de itens (que é bloqueada pelo Azure).

Via Portal

Navegue até Resource groups > rg-contosofarma-lab
Filtre os recursos pelo tipo vault e confirme que existem dois recursos: rsv-contosofarma (tipo Microsoft.RecoveryServices/vaults) e bv-contosofarma (tipo Microsoft.DataProtection/backupVaults)
Abra rsv-contosofarma > Navegue até Properties > Backup Configuration
Anote o valor de Storage replication type: deve ser Geo-redundant
Abra bv-contosofarma > Navegue até Properties
Anote o valor de Redundancy: deve ser Locally-redundant
Confirme que Immutability está como Enabled

Via CLI

# Listar todos os vaults no resource group
az resource list \
  --resource-group rg-contosofarma-lab \
  --query "[?contains(type,'vault') || contains(type,'Vault')].{Name:name, Type:type, Location:location}" \
  --output table

# Verificar redundância do Recovery Services vault
az backup vault backup-properties show \
  --resource-group rg-contosofarma-lab \
  --name rsv-contosofarma \
  --query "{StorageType:storageModelType, CrossRegionRestore:crossRegionRestoreFlag}" \
  --output table

# Verificar redundância do Backup vault
az dataprotection backup-vault show \
  --resource-group rg-contosofarma-lab \
  --vault-name bv-contosofarma \
  --query "{Redundancy:properties.storageSettings[0].type}" \
  --output table

Esta validação confirma que o ambiente possui dois cofres distintos com configurações de redundância diferentes e apropriadas para cada tipo de workload. Após qualquer item ser protegido no Recovery Services vault, a alteração de redundância será bloqueada permanentemente, o que reforça a importância de configurá-la corretamente nesta etapa inicial.

Tarefa 1.4 — Criar o Resource Group da região secundária

O Resource Group da região secundária será necessário na Fase 3 para o Azure Site Recovery. Crie-o agora para evitar dependências futuras.

Via Portal

Navegue até Resource groups > Clique em Create
Preencha Resource group com rg-contosofarma-dr
Selecione Region como East US 2
Clique em Review + create > Clique em Create

Via CLI

az group create \
  --name rg-contosofarma-dr \
  --location eastus2

O Resource Group rg-contosofarma-dr servirá como contêiner para os recursos replicados pelo Site Recovery na região secundária.

Fase 2 — Políticas de Backup e Operações de Backup/Restore

Nesta fase, você criará políticas de backup personalizadas para as VMs e configurará a proteção efetiva. Em seguida, executará operações de backup sob demanda e realizará uma restauração para validar a integridade dos dados. Todos os recursos desta fase dependem do Recovery Services vault rsv-contosofarma e do Backup vault bv-contosofarma criados na Fase 1.

Tarefa 2.1 — Criar uma política de backup personalizada para VMs

A política padrão do Azure Backup faz snapshot diário às 0h UTC com retenção de 30 dias. A Contoso Farma precisa de backups diários às 22h BRT (01h UTC) com retenção de 30 dias para pontos diários, 12 semanas para semanais e 6 meses para mensais. Nesta tarefa, você criará essa política personalizada.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Backup policies (no menu lateral, seção Manage)
Clique em Add
Selecione Policy type como Azure Virtual Machine
Preencha Policy name com policy-vm-diario
Em Backup schedule:
- Selecione Frequency como Daily
- Defina Time como 1:00 AM (UTC, equivalente a 22h BRT)
Em Instant Restore, mantenha a retenção de snapshots em 2 dias
Em Retention range:
- Daily backup point: Retention como 30 days
- Habilite Weekly backup point: selecione Sunday, retention de 12 weeks
- Habilite Monthly backup point: selecione First Sunday, retention de 6 months
Em Tiering, mantenha desabilitado por ora
Clique em Create

Via CLI

# Primeiro, obter a política padrão como referência (JSON)
az backup policy show \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --name DefaultPolicy \
  --output json > /tmp/default-policy.json

# Criar a política personalizada usando um arquivo JSON editado
# O JSON deve conter schedule às 01:00 UTC e retenções configuradas
az backup policy create \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --name policy-vm-diario \
  --backup-management-type AzureIaasVM \
  --policy '{
    "policyType": "V2",
    "instantRpRetentionRangeInDays": 2,
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicyV2",
      "scheduleRunFrequency": "Daily",
      "dailySchedule": {
        "scheduleRunTimes": ["2025-01-01T01:00:00Z"]
      }
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {
        "retentionTimes": ["2025-01-01T01:00:00Z"],
        "retentionDuration": {"count": 30, "durationType": "Days"}
      },
      "weeklySchedule": {
        "daysOfTheWeek": ["Sunday"],
        "retentionTimes": ["2025-01-01T01:00:00Z"],
        "retentionDuration": {"count": 12, "durationType": "Weeks"}
      },
      "monthlySchedule": {
        "retentionScheduleFormatType": "Weekly",
        "retentionScheduleWeekly": {
          "daysOfTheWeek": ["Sunday"],
          "weeksOfTheMonth": ["First"]
        },
        "retentionTimes": ["2025-01-01T01:00:00Z"],
        "retentionDuration": {"count": 6, "durationType": "Months"}
      }
    }
  }'

# Confirmar criação
az backup policy list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[].{Name:name, Type:properties.backupManagementType}" \
  --output table

A política personalizada garante que os backups ocorram fora do horário comercial brasileiro e que a retenção atenda aos requisitos de conformidade da auditoria, com pontos de recuperação diários, semanais e mensais.

Tarefa 2.2 — Habilitar backup nas VMs com a política personalizada

Com a política criada, é necessário associá-la às VMs vm-web-01 e vm-sql-01. Esta tarefa configura a proteção efetiva de ambas as máquinas virtuais.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em + Backup (na seção Getting started)
Em Where is your workload running?, selecione Azure
Em What do you want to back up?, selecione Virtual machine
Clique em Backup
Em Backup policy, selecione policy-vm-diario (a política criada na tarefa anterior)
Clique em Add na seção Virtual Machines
Marque as VMs vm-web-01 e vm-sql-01
Clique em OK
Clique em Enable backup
Aguarde a notificação de que a configuração foi concluída

Via CLI

# Habilitar backup para vm-web-01
az backup protection enable-for-vm \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --vm vm-web-01 \
  --policy-name policy-vm-diario

# Habilitar backup para vm-sql-01
az backup protection enable-for-vm \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --vm vm-sql-01 \
  --policy-name policy-vm-diario

# Verificar que ambas as VMs estão protegidas
az backup item list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[].{Name:properties.friendlyName, Policy:properties.policyName, Status:properties.protectionStatus}" \
  --output table

Ambas as VMs agora estão associadas à política de backup. O Azure instalará automaticamente a extensão de backup nas VMs na primeira execução. O status deve aparecer como Protected após a configuração.

Tarefa 2.3 — Executar backup sob demanda e monitorar o progresso

Não é necessário esperar o horário agendado. Nesta tarefa, você disparará um backup sob demanda de vm-web-01 para gerar um ponto de recuperação imediato e monitorará o progresso da operação.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Backup items (no menu lateral)
Clique em Azure Virtual Machine
Localize vm-web-01 na lista e clique nos três pontos (...) na linha correspondente
Clique em Backup now
Em Retain Backup Till, defina uma data 30 dias à frente
Clique em OK para iniciar o backup
Navegue até Backup jobs (no menu lateral)
Observe o job recém-criado para vm-web-01 com status In progress
Aguarde até que o status mude para Completed (pode levar de 15 a 40 minutos)
Anote o tempo de conclusão para referência

Via CLI

# Disparar backup sob demanda para vm-web-01
az backup protection backup-now \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-web-01 \
  --item-name vm-web-01 \
  --backup-management-type AzureIaasVM \
  --retain-until $(date -d "+30 days" +%d-%m-%Y)

# Monitorar o status do job
az backup job list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[?properties.entityFriendlyName=='vm-web-01'].{Operation:properties.operation, Status:properties.status, StartTime:properties.startTime}" \
  --output table

O backup sob demanda cria um snapshot incremental do disco da VM. A primeira execução transfere todos os dados e pode levar mais tempo. Execuções subsequentes transferem apenas os blocos alterados.

Tarefa 2.4 — Restaurar arquivos de uma VM a partir do ponto de recuperação

Nesta tarefa, você executará uma restauração de nível de arquivo (File Recovery) a partir do ponto de recuperação criado na tarefa anterior. Esse tipo de restauração monta os discos do backup como unidade de rede, permitindo recuperar arquivos específicos sem restaurar a VM inteira. Adicionalmente, você tentará restaurar para uma VM com configuração de rede diferente para validar o cenário adverso de conflito de rede.

Via Portal

Parte A: File Recovery (restauração de arquivos individuais)

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Backup items > Azure Virtual Machine
Clique em vm-web-01
Clique em File Recovery (no topo da página)
Em Select recovery point, escolha o ponto mais recente
Clique em Download Executable
O script baixado deve ser executado na VM de onde os dados serão acessados
Conecte-se à vm-web-01 via RDP
Execute o script baixado como administrador na VM
O script montará os volumes do backup como letras de unidade
Navegue pelos volumes montados e copie os arquivos desejados para um local seguro
Retorne ao portal e clique em Unmount Disks quando concluir

Parte B: Restaurar VM completa para validar cenário de conflito

Ainda na página de vm-web-01 no Backup items, clique em Restore VM
Em Restore point, selecione o ponto mais recente
Em Restore configuration, selecione Create new
Preencha Virtual machine name com vm-web-01-restored
Selecione Resource group como rg-contosofarma-lab
Selecione Virtual network como vnet-contosofarma
Selecione Subnet como snet-web
Observe que o Azure atribuirá um novo IP privado automaticamente (sem conflito com a VM original)
Clique em Restore
Navegue até Backup jobs para monitorar o progresso
Após a conclusão, navegue até Virtual machines e confirme que vm-web-01-restored existe
Verifique que a VM restaurada recebeu um IP diferente de vm-web-01 navegando até Networking em ambas

Via CLI

# Listar pontos de recuperação disponíveis
az backup recoverypoint list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-web-01 \
  --item-name vm-web-01 \
  --backup-management-type AzureIaasVM \
  --query "[].{Name:name, Time:properties.recoveryPointTime, Type:properties.recoveryPointType}" \
  --output table

# Obter o ID do ponto de recuperação mais recente
RP_NAME=$(az backup recoverypoint list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-web-01 \
  --item-name vm-web-01 \
  --backup-management-type AzureIaasVM \
  --query "[0].name" \
  --output tsv)

# Restaurar como nova VM
az backup restore restore-disks \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-web-01 \
  --item-name vm-web-01 \
  --rp-name $RP_NAME \
  --storage-account stcontosofarmadiag \
  --target-resource-group rg-contosofarma-lab

# Monitorar job de restauração
az backup job list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[?properties.operation=='Restore'].{Status:properties.status, StartTime:properties.startTime}" \
  --output table

A restauração em nível de arquivo é a abordagem mais rápida e menos disruptiva para recuperar dados específicos. A restauração completa de VM cria discos na storage account indicada, que podem então ser usados para criar uma nova VM. A verificação de IPs distintos confirma que o Azure previne automaticamente conflitos de rede durante a restauração na mesma sub-rede.

Tarefa 2.5 — Criar política de backup para Blobs no Backup Vault

Para completar a cobertura de backup, configure a proteção dos blobs do Storage Account stcontosofarmadiag usando o Backup vault bv-contosofarma. Esta política utilizará backup operacional (operational backup) para blobs.

Via Portal

Navegue até Backup vaults > bv-contosofarma
Clique em + Backup (seção Getting started)
Em Datasource type, selecione Azure Blobs (Azure Storage)
Clique em Continue
Em Backup policy, clique em Create a new policy
Preencha Policy name com policy-blob-semanal
Defina Retention como 30 days
Clique em Create
Em Backup Instances, clique em + Add
Selecione o Storage Account stcontosofarmadiag
Clique em Validate
Se a validação reportar erro de permissão, clique em Assign missing roles e aguarde a propagação (pode levar até 5 minutos)
Valide novamente e, se bem-sucedido, clique em Configure backup

Via CLI

# Criar a política de backup para blobs
az dataprotection backup-policy create \
  --resource-group rg-contosofarma-lab \
  --vault-name bv-contosofarma \
  --name policy-blob-semanal \
  --datasource-type AzureBlob \
  --policy '{
    "policyRules": [{
      "name": "Default",
      "objectType": "AzureRetentionRule",
      "isDefault": true,
      "lifecycles": [{
        "deleteAfter": {
          "objectType": "AbsoluteDeleteOption",
          "duration": "P30D"
        },
        "sourceDataStore": {
          "dataStoreType": "OperationalStore",
          "objectType": "DataStoreInfoBase"
        }
      }]
    }],
    "datasourceTypes": ["Microsoft.Storage/storageAccounts/blobServices"],
    "objectType": "BackupPolicy"
  }'

# Obter o ID do Storage Account
STORAGE_ID=$(az storage account show \
  --resource-group rg-contosofarma-lab \
  --name stcontosofarmadiag \
  --query id --output tsv)

# Configurar a instância de backup
az dataprotection backup-instance create \
  --resource-group rg-contosofarma-lab \
  --vault-name bv-contosofarma \
  --backup-instance "{
    \"objectType\": \"BackupInstanceResource\",
    \"properties\": {
      \"dataSourceInfo\": {
        \"resourceID\": \"$STORAGE_ID\",
        \"resourceUri\": \"$STORAGE_ID\",
        \"datasourceType\": \"Microsoft.Storage/storageAccounts/blobServices\",
        \"resourceName\": \"stcontosofarmadiag\",
        \"resourceType\": \"Microsoft.Storage/storageAccounts\",
        \"resourceLocation\": \"brazilsouth\",
        \"objectType\": \"Datasource\"
      },
      \"policyInfo\": {
        \"policyId\": \"/subscriptions/<SUB_ID>/resourceGroups/rg-contosofarma-lab/providers/Microsoft.DataProtection/backupVaults/bv-contosofarma/backupPolicies/policy-blob-semanal\"
      },
      \"objectType\": \"BackupInstance\"
    }
  }"

O backup operacional de blobs é contínuo e permite restauração point-in-time dentro do período de retenção configurado. A atribuição de roles é necessária porque o Backup vault precisa de permissão Storage Account Backup Contributor na Storage Account de destino.

Fase 3 — Azure Site Recovery e Failover

Nesta fase, você configurará o Azure Site Recovery para replicar a VM vm-web-01 da região Brazil South para East US 2, realizará um test failover para validar a replicação e, em seguida, executará um failover completo para a região secundária. Esta fase utiliza o Recovery Services vault rsv-contosofarma da Fase 1 e o Resource Group rg-contosofarma-dr criado na Tarefa 1.4.

Tarefa 3.1 — Verificar o estado atual da VM antes de habilitar a replicação

Antes de configurar o Site Recovery, é fundamental validar o estado atual da VM para garantir que ela atende aos pré-requisitos de replicação. VMs com certas configurações (discos não gerenciados, extensões incompatíveis ou limitações regionais) podem falhar ao habilitar a replicação.

Via Portal

Navegue até Virtual machines > vm-web-01
Verifique na aba Overview que o Status é Running
Navegue até Disks (menu lateral)
Confirme que todos os discos são Managed disks (obrigatório para ASR)
Anote o nome do disco OS e seu tipo (Standard SSD ou Premium SSD)
Navegue até Networking (menu lateral)
Anote o IP privado atual, a sub-rede e o NSG associados
Navegue até Extensions + applications (menu lateral)
Verifique se há extensões que possam conflitar com o agente do Site Recovery

Via CLI

# Verificar status da VM
az vm show \
  --resource-group rg-contosofarma-lab \
  --name vm-web-01 \
  --query "{Status:provisioningState, VMSize:hardwareProfile.vmSize}" \
  --output table

# Verificar que usa discos gerenciados
az vm show \
  --resource-group rg-contosofarma-lab \
  --name vm-web-01 \
  --query "storageProfile.osDisk.{Name:name, ManagedDisk:managedDisk.id, DiskType:managedDisk.storageAccountType}" \
  --output table

# Listar extensões instaladas
az vm extension list \
  --resource-group rg-contosofarma-lab \
  --vm-name vm-web-01 \
  --query "[].{Name:name, Publisher:publisher, Status:provisioningState}" \
  --output table

# Verificar IP atual
az vm list-ip-addresses \
  --resource-group rg-contosofarma-lab \
  --name vm-web-01 \
  --output table

A validação prévia evita falhas durante a habilitação da replicação. VMs com discos não gerenciados precisariam de conversão antes de prosseguir, e extensões problemáticas precisariam ser removidas.

Tarefa 3.2 — Configurar o Azure Site Recovery para replicar vm-web-01

Agora você habilitará a replicação da VM vm-web-01 para a região East US 2 usando o Azure Site Recovery. O ASR criará automaticamente recursos de cache na região de origem e recursos de destino na região secundária.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Site Recovery (no menu lateral, seção Getting started)
Em Azure virtual machines, clique em Enable replication (Step 1)
Na aba Source:
- Selecione Source location como Brazil South
- Selecione Subscription com sua assinatura
- Selecione Resource group como rg-contosofarma-lab
- Selecione Deployment model como Resource Manager
Clique em Next
Na aba Virtual machines, marque vm-web-01
Clique em Next
Na aba Replication settings:
- Selecione Target location como East US 2
- Selecione Target resource group como rg-contosofarma-dr
- Verifique que o Azure sugere criar automaticamente: VNet de destino, Storage Account de cache e Availability set (se aplicável)
- Em Replication policy, observe que o Azure cria uma política padrão com RPO de 24 horas e retenção de pontos de recuperação de 24 horas
- Clique em Customize para ajustar: defina Recovery point retention como 72 hours e App-consistent snapshot frequency como 4 hours
Clique em Next
Na aba Review, confirme todas as configurações
Clique em Enable replication
Navegue até Site Recovery > Replicated items
Observe o status de vm-web-01 como Enabling protection (pode levar de 30 a 60 minutos até mudar para Protected)

Via CLI

# Obter o ID do fabric (source)
az site-recovery fabric create \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --location brazilsouth

# Habilitar replicação via CLI (método simplificado)
# Note: a CLI do Site Recovery é complexa; o portal é mais prático
# O comando abaixo ilustra a estrutura

az vm replication enable \
  --resource-group rg-contosofarma-lab \
  --name vm-web-01 \
  --partner-vault rsv-contosofarma \
  --target-resource-group rg-contosofarma-dr \
  --target-region eastus2

# Monitorar status da replicação
az site-recovery replicated-item list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --protection-container-name "asr-a2a-default-brazilsouth" \
  --query "[].{VM:properties.friendlyName, Status:properties.replicationHealth, State:properties.protectionState}" \
  --output table

O Azure Site Recovery iniciou a replicação inicial da VM, copiando todos os dados dos discos para a região secundária. A política de replicação personalizada com RPO de 72 horas e snapshots consistentes com aplicação a cada 4 horas atende ao requisito de RTO da Contoso Farma.

Tarefa 3.3 — Executar Test Failover para validar a replicação

Antes de executar um failover real, é essencial validar a replicação com um test failover. O test failover cria a VM na região de destino em uma rede isolada, sem impactar o ambiente de produção.

Via Portal

Aguarde até que o status da replicação de vm-web-01 em Replicated items esteja como Protected (Health: Normal)
Clique em vm-web-01 na lista de Replicated items
Clique em Test failover (na barra de ferramentas superior)
Em Recovery Point, selecione Latest processed (menor RPO)
Em Azure virtual network, selecione Create new e nomeie como vnet-dr-test-isolated
Defina o espaço de endereço como 10.1.0.0/16 com sub-rede 10.1.1.0/24
Clique em OK
Acompanhe o progresso em Site Recovery jobs
Após a conclusão, navegue até Virtual machines
Confirme que existe a VM vm-web-01-test na região East US 2
Conecte-se via RDP à VM de teste e valide que o sistema operacional está funcional
Retorne a Replicated items > vm-web-01
Clique em Cleanup test failover
Marque a caixa Testing is complete. Delete test failover virtual machine(s)
Clique em OK

Via CLI

# Executar test failover (após replicação concluída)
az site-recovery replicated-item test-failover \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --protection-container-name "asr-a2a-default-brazilsouth" \
  --replicated-item-name vm-web-01 \
  --failover-direction PrimaryToRecovery \
  --network-type VmNetworkAsInput \
  --recovery-point latest

# Verificar status do test failover
az site-recovery job list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[?properties.targetObjectName=='vm-web-01' && contains(properties.scenarioName,'TestFailover')].{Status:properties.state, StartTime:properties.startTime}" \
  --output table

# Após validação, limpar o test failover
az site-recovery replicated-item test-failover-cleanup \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --protection-container-name "asr-a2a-default-brazilsouth" \
  --replicated-item-name vm-web-01 \
  --comments "Test failover validated successfully"

O test failover confirmou que a replicação está funcional e que a VM pode ser instanciada na região de destino. A rede isolada garante que nenhum tráfego de produção é afetado durante o teste. A limpeza remove todos os recursos temporários criados.

Tarefa 3.4 — Executar Failover completo para a região secundária

Simule uma indisponibilidade da região Brazil South executando um failover planejado (planned failover) da VM vm-web-01 para East US 2. Após o failover, você validará a VM na região secundária e executará o commit.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma > Site Recovery > Replicated items
Clique em vm-web-01
Clique em Failover (na barra de ferramentas, diferente de "Test failover")
Observe o aviso: "A source VM will be shut down. This causes downtime."
Em Recovery Point, selecione Latest processed
Marque a opção Shut down machine before beginning failover (garante zero perda de dados)
Clique em OK
Navegue até Site Recovery jobs e acompanhe o progresso
Após a conclusão, navegue até Virtual machines
Confirme que vm-web-01 agora existe na região East US 2 e está em estado Running
Verifique o endereço IP da VM na região de destino em Networking
Retorne a Replicated items > vm-web-01
Clique em Commit
Confirme o commit do failover

Via CLI

# Executar failover
az site-recovery replicated-item failover \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --protection-container-name "asr-a2a-default-brazilsouth" \
  --replicated-item-name vm-web-01 \
  --failover-direction PrimaryToRecovery \
  --recovery-point latest

# Monitorar o job de failover
az site-recovery job list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[?contains(properties.scenarioName,'Failover')].{Scenario:properties.scenarioName, Status:properties.state}" \
  --output table

# Após validação da VM no destino, commit do failover
az site-recovery replicated-item commit \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --protection-container-name "asr-a2a-default-brazilsouth" \
  --replicated-item-name vm-web-01

O failover desligou a VM na região de origem, aplicou os dados replicados mais recentes e instanciou a VM na região East US 2. O commit do failover finaliza a operação e limpa os dados de replicação pendentes. Para reproteger a VM (habilitar replicação reversa de East US 2 para Brazil South), seria necessário configurar a replicação reversa a partir de Replicated items.

Tarefa 3.5 — Reproteger a VM após o failover

Após o failover e commit, a VM em East US 2 não está mais protegida. Para restabelecer a resiliência, habilite a replicação reversa (re-protect), que replicará a VM de East US 2 de volta para Brazil South.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma > Site Recovery > Replicated items
Clique em vm-web-01 (agora localizada em East US 2)
Clique em Re-protect (na barra de ferramentas)
Confirme que a Target region é Brazil South
Selecione o Resource Group de destino como rg-contosofarma-lab
Verifique as configurações de rede e storage account de cache
Clique em OK
Acompanhe o progresso em Site Recovery jobs
Aguarde o status mudar para Protected em Replicated items

Via CLI

# Reproteger a VM (replicação reversa)
az site-recovery replicated-item reprotect \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --fabric-name fabric-brazilsouth \
  --protection-container-name "asr-a2a-default-brazilsouth" \
  --replicated-item-name vm-web-01 \
  --direction RecoveryToPrimary

A reprotecção restabelece a replicação contínua, agora no sentido inverso. Se a região East US 2 sofrer uma falha no futuro, será possível realizar o failback para Brazil South usando o mesmo processo.

Fase 4 — Relatórios e Alertas para Backups

Nesta fase, você configurará o monitoramento proativo da solução de backup. Utilizará o Log Analytics workspace law-contosofarma criado nos pré-requisitos para habilitar os relatórios do Azure Backup e configurará alertas para notificação de falhas de backup e operações críticas. Esta fase utiliza o Recovery Services vault rsv-contosofarma da Fase 1.

Tarefa 4.1 — Configurar Diagnostic Settings no Recovery Services Vault

Para que os relatórios e alertas funcionem, o vault precisa enviar seus logs de diagnóstico para o Log Analytics workspace. Nesta tarefa, você configurará as Diagnostic Settings e validará que os dados começam a fluir.

Via Portal

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Diagnostic settings (no menu lateral, seção Monitoring)
Clique em + Add diagnostic setting
Preencha Diagnostic setting name com diag-backup-law
Em Logs, marque as seguintes categorias:
- CoreAzureBackup
- AddonAzureBackupJobs
- AddonAzureBackupPolicy
- AddonAzureBackupAlerts
- AddonAzureBackupStorage
- AddonAzureBackupProtectedInstance
Em Destination details, marque Send to Log Analytics workspace
Selecione Subscription com sua assinatura
Selecione Log Analytics workspace como law-contosofarma
Confirme que o modo Resource specific está selecionado (recomendado para Backup Reports)
Clique em Save

Via CLI

# Obter o ID do Recovery Services vault
VAULT_ID=$(az backup vault show \
  --resource-group rg-contosofarma-lab \
  --name rsv-contosofarma \
  --query id --output tsv)

# Obter o ID do Log Analytics workspace
LAW_ID=$(az monitor log-analytics workspace show \
  --resource-group rg-contosofarma-lab \
  --workspace-name law-contosofarma \
  --query id --output tsv)

# Criar o diagnostic setting
az monitor diagnostic-settings create \
  --name diag-backup-law \
  --resource $VAULT_ID \
  --workspace $LAW_ID \
  --logs '[
    {"category":"CoreAzureBackup","enabled":true},
    {"category":"AddonAzureBackupJobs","enabled":true},
    {"category":"AddonAzureBackupPolicy","enabled":true},
    {"category":"AddonAzureBackupAlerts","enabled":true},
    {"category":"AddonAzureBackupStorage","enabled":true},
    {"category":"AddonAzureBackupProtectedInstance","enabled":true}
  ]'

# Verificar a configuração
az monitor diagnostic-settings show \
  --name diag-backup-law \
  --resource $VAULT_ID \
  --query "{Name:name, Workspace:workspaceId, LogCategories:logs[].{Category:category, Enabled:enabled}}" \
  --output json

As Diagnostic Settings encaminham os logs operacionais do vault para o workspace. Pode levar até 24 horas para os dados aparecerem nos Backup Reports. As categorias selecionadas cobrem jobs, políticas, alertas, armazenamento e instâncias protegidas.

Tarefa 4.2 — Acessar e interpretar Backup Reports

Os Backup Reports consolidam dados de todos os vaults configurados para enviar diagnósticos ao mesmo workspace. Nesta tarefa, você acessará os relatórios e interpretará as informações disponíveis.

Via Portal

Navegue até Backup center (pesquise na barra de busca)
Clique em Backup Reports (no menu lateral, seção Monitoring + Reporting)
Na aba Configure, selecione Log Analytics workspace como law-contosofarma
Clique em a aba Summary
Observe os seguintes painéis (os dados podem levar até 24h para popular):
- Backup Instances: deve mostrar as VMs vm-web-01 e vm-sql-01
- Backup Jobs: deve exibir o job sob demanda executado na Tarefa 2.3
- Backup Storage Consumed: volume de dados armazenados
Clique em a aba Backup Items
Filtre por Backup Management Type = Azure Virtual Machine
Confirme que ambas as VMs aparecem com status de proteção ativo
Clique em a aba Jobs
Verifique que o job de backup sob demanda da vm-web-01 aparece com status Completed
Clique em a aba Policy Adherence
Verifique se há itens com status Not compliant (estes indicariam backups falhados)

Via CLI

# Consultar dados de jobs de backup via Log Analytics
az monitor log-analytics query \
  --workspace law-contosofarma \
  --analytics-query "AddonAzureBackupJobs
    | where TimeGenerated > ago(7d)
    | project JobOperation, JobStatus, BackupItemFriendlyName, JobStartDateTime, JobDuration
    | order by JobStartDateTime desc
    | take 10" \
  --output table

# Consultar instâncias protegidas
az monitor log-analytics query \
  --workspace law-contosofarma \
  --analytics-query "CoreAzureBackup
    | where TimeGenerated > ago(7d)
    | where OperationName == 'BackupItem'
    | project BackupItemFriendlyName, ProtectionState, BackupManagementType
    | distinct BackupItemFriendlyName, ProtectionState, BackupManagementType" \
  --output table

Os relatórios fornecem visibilidade centralizada de todos os workloads protegidos. A aba Policy Adherence é particularmente importante para identificar VMs que não estão em conformidade com a política de backup, o que poderia indicar falhas silenciosas.

Tarefa 4.3 — Configurar alertas para falhas de backup

Para atender ao requisito de monitoramento proativo, configure alertas que notifiquem a equipe de TI quando um job de backup falhar. Nesta tarefa, você configurará alertas integrados do Azure Backup e também criará um alerta personalizado baseado em Log Analytics.

Via Portal

Parte A: Alertas integrados do Azure Backup

Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Alerts (no menu lateral, seção Monitoring)
Observe os alertas existentes (pode estar vazio se nenhum erro ocorreu)
Navegue até Backup center > Alerts
Em Alert type filter, selecione Built-in Azure Monitor alerts
Confirme que os tipos de alerta incluem: Backup failure, Restore failure, Delete backup data

Parte B: Criar regra de alerta personalizada via Log Analytics

Navegue até Monitor (pesquise na barra de busca)
Clique em Alerts > Clique em + Create > Alert rule
Em Scope, clique em Select scope
Filtre por tipo Log Analytics workspace
Selecione law-contosofarma
Clique em Apply
Em Condition, clique em Add condition
Selecione signal type como Custom log search
No campo de query, insira:

AddonAzureBackupJobs
| where JobStatus == "Failed"
| where TimeGenerated > ago(1h)
| project BackupItemFriendlyName, JobOperation, JobFailureCode, TimeGenerated

Em Alert logic:
- Defina Operator como Greater than
- Defina Threshold value como 0
- Defina Frequency of evaluation como Every 15 minutes
- Defina Lookback period como 1 hour
Clique em Next
Em Actions, clique em Create action group
Preencha Action group name com ag-backup-alerts
Em Notifications, adicione:
- Tipo: Email/SMS/Push/Voice
- Nome: notify-backup-team
- Email: insira o endereço de email da equipe de backup
Clique em Review + create > Clique em Create
Em Details:
- Selecione Severity como Sev 2 - Warning
- Preencha Alert rule name com alert-backup-failure
Clique em Review + create > Clique em Create

Via CLI

# Criar action group
az monitor action-group create \
  --resource-group rg-contosofarma-lab \
  --name ag-backup-alerts \
  --short-name BackupAlrt \
  --action email notify-backup-team backup-team@contosofarma.com

# Obter ID do Log Analytics workspace
LAW_ID=$(az monitor log-analytics workspace show \
  --resource-group rg-contosofarma-lab \
  --workspace-name law-contosofarma \
  --query id --output tsv)

# Criar a regra de alerta
az monitor scheduled-query create \
  --resource-group rg-contosofarma-lab \
  --name alert-backup-failure \
  --scopes $LAW_ID \
  --condition "count 'AddonAzureBackupJobs | where JobStatus == \"Failed\" | where TimeGenerated > ago(1h)' > 0" \
  --severity 2 \
  --evaluation-frequency 15m \
  --window-size 1h \
  --action-groups ag-backup-alerts \
  --description "Alerta disparado quando um job de backup falha"

# Verificar a regra criada
az monitor scheduled-query list \
  --resource-group rg-contosofarma-lab \
  --query "[].{Name:name, Severity:severity, Enabled:enabled}" \
  --output table

Os alertas integrados do Azure Backup detectam automaticamente falhas e problemas de segurança. O alerta personalizado via Log Analytics adiciona uma camada extra de monitoramento com consulta KQL específica, garantindo que qualquer falha de backup nas últimas 1 hora gere uma notificação por email para a equipe.

Tarefa 4.4 — Simular falha e validar o disparo do alerta

Para confirmar que o sistema de alertas funciona corretamente, force uma condição de falha e verifique se o alerta é disparado. Nesta tarefa, você tentará desligar a VM e disparar um backup enquanto ela está parada para gerar uma condição de job com comportamento inesperado.

Via Portal

Navegue até Virtual machines > vm-sql-01
Clique em Stop > Confirme para deallocar a VM
Aguarde o status mudar para Stopped (deallocated)
Navegue até Recovery Services vaults > rsv-contosofarma
Clique em Backup items > Azure Virtual Machine
Clique nos três pontos (...) ao lado de vm-sql-01
Clique em Backup now
Defina a data de retenção e clique em OK
Navegue até Backup jobs
Observe o job de backup para vm-sql-01
O Azure Backup pode concluir com sucesso mesmo com a VM desalocada (utilizando snapshot do disco), porém em cenários onde extensões precisam ser atualizadas, pode gerar um warning
Navegue até Monitor > Alerts
Verifique se algum alerta foi gerado nos últimos 30 minutos
Se nenhum alerta de falha foi gerado (pois o backup de VM desalocada pode ter sucesso), reinicie a VM com az vm start --resource-group rg-contosofarma-lab --name vm-sql-01
Registre o comportamento observado: o Azure Backup suporta backup de VMs desalocadas utilizando snapshots de disco, mas alertas de warning podem ser gerados pela falta do agente

Via CLI

# Parar (deallocar) a VM
az vm deallocate \
  --resource-group rg-contosofarma-lab \
  --name vm-sql-01

# Disparar backup sob demanda
az backup protection backup-now \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-sql-01 \
  --item-name vm-sql-01 \
  --backup-management-type AzureIaasVM \
  --retain-until $(date -d "+30 days" +%d-%m-%Y)

# Verificar status do job
az backup job list \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --query "[?properties.entityFriendlyName=='vm-sql-01'].{Operation:properties.operation, Status:properties.status, Warnings:properties.extendedInfo.propertyBag}" \
  --output json

# Verificar alertas gerados
az monitor alert list \
  --resource-group rg-contosofarma-lab \
  --query "[].{Name:name, Severity:properties.severity, Status:properties.essentials.monitorCondition}" \
  --output table

# Reiniciar a VM
az vm start \
  --resource-group rg-contosofarma-lab \
  --name vm-sql-01

Este teste valida o comportamento do sistema de alertas em um cenário real. O Azure Backup pode processar backups de VMs desalocadas (backup crash-consistent via snapshot de disco), mas isso gera backups sem consistência de aplicação. A diferença entre backup app-consistent e crash-consistent é um ponto relevante para o exame AZ-104.

Validação Final

Após concluir todas as fases, verifique os seguintes critérios para confirmar a execução completa do laboratório:

Critério 1: Cofres criados e configurados corretamente

Navegue até rg-contosofarma-lab no portal Azure e confirme que os recursos rsv-contosofarma (Recovery Services vault com GRS e Cross Region Restore habilitado) e bv-contosofarma (Backup vault com LRS e imutabilidade habilitada) existem. Alternativamente, execute az resource list --resource-group rg-contosofarma-lab --query "[?contains(type,'vault')]" e valide os dois recursos.

Critério 2: VMs protegidas com política personalizada

Navegue até rsv-contosofarma > Backup items > Azure Virtual Machine e confirme que vm-web-01 e vm-sql-01 estão listadas com a política policy-vm-diario associada e status Protected. Verifique que existe ao menos um ponto de recuperação concluído para vm-web-01.

Critério 3: Restauração executada com sucesso (validação comportamental)

Navegue até Virtual machines e confirme que vm-web-01-restored existe na região Brazil South. Acesse a VM restaurada e confirme que ela possui um IP privado diferente da VM original, comprovando que a restauração criou um recurso funcional independente na mesma sub-rede sem conflito de rede.

Critério 4: Failover concluído para região secundária

Navegue até rsv-contosofarma > Site Recovery > Replicated items e confirme que vm-web-01 mostra a região de destino como East US 2 com status Protected (após re-protect). Navegue até Virtual machines, filtre pela região East US 2 e confirme que vm-web-01 está com status Running nessa região.

Critério 5: Alertas e relatórios operacionais

Navegue até Monitor > Alerts e confirme que a regra alert-backup-failure está listada e habilitada. Navegue até Backup center > Backup Reports, selecione o workspace law-contosofarma e confirme que as abas Summary, Backup Items e Jobs exibem dados correspondentes aos backups executados.

Cleanup do Ambiente

Siga as instruções abaixo para remover todos os recursos criados durante o laboratório, na ordem inversa à criação, evitando cobranças desnecessárias.

Via Portal

Remover proteção de backup das VMs:
- Navegue até Recovery Services vaults > rsv-contosofarma > Backup items > Azure Virtual Machine
- Para cada VM (vm-web-01, vm-sql-01), clique nos três pontos > Stop backup
- Selecione Delete backup data
- Digite o nome do item para confirmar e clique em Stop backup
- Repita para cada VM
Desabilitar replicação do Site Recovery:
- Navegue até rsv-contosofarma > Site Recovery > Replicated items
- Selecione vm-web-01 > Clique em Disable replication
- Confirme a remoção
Remover a instância de backup de blobs:
- Navegue até Backup vaults > bv-contosofarma > Backup instances
- Selecione a instância de stcontosofarmadiag
- Clique em Stop protection > Delete
Remover a regra de alerta e action group:
- Navegue até Monitor > Alerts > Alert rules
- Selecione alert-backup-failure > Clique em Delete
- Navegue até Monitor > Alerts > Action groups
- Selecione ag-backup-alerts > Clique em Delete
Excluir a VM restaurada:
- Navegue até Virtual machines > vm-web-01-restored > Clique em Delete
- Marque a opção para excluir os discos associados
Excluir os Resource Groups (remove todos os recursos filhos):
- Navegue até Resource groups > rg-contosofarma-dr > Clique em Delete resource group
- Digite o nome do resource group para confirmar > Clique em Delete
- Navegue até Resource groups > rg-contosofarma-lab > Clique em Delete resource group
- Digite o nome do resource group para confirmar > Clique em Delete
Confirmar exclusão:
- Aguarde de 5 a 10 minutos
- Navegue até Resource groups e confirme que rg-contosofarma-lab e rg-contosofarma-dr não aparecem mais na lista

Via CLI

# 1. Remover proteção de backup das VMs
az backup protection disable \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-web-01 \
  --item-name vm-web-01 \
  --backup-management-type AzureIaasVM \
  --delete-backup-data true --yes

az backup protection disable \
  --resource-group rg-contosofarma-lab \
  --vault-name rsv-contosofarma \
  --container-name vm-sql-01 \
  --item-name vm-sql-01 \
  --backup-management-type AzureIaasVM \
  --delete-backup-data true --yes

# 2. Remover alerta e action group
az monitor scheduled-query delete \
  --resource-group rg-contosofarma-lab \
  --name alert-backup-failure --yes

az monitor action-group delete \
  --resource-group rg-contosofarma-lab \
  --name ag-backup-alerts

# 3. Excluir VM restaurada
az vm delete \
  --resource-group rg-contosofarma-lab \
  --name vm-web-01-restored --yes

# 4. Excluir Resource Group da região DR (e todos os recursos filhos)
az group delete --name rg-contosofarma-dr --yes --no-wait

# 5. Excluir Resource Group principal (e todos os recursos filhos)
az group delete --name rg-contosofarma-lab --yes --no-wait

# 6. Confirmar exclusão
az group exists --name rg-contosofarma-lab
# Output esperado: false

az group exists --name rg-contosofarma-dr
# Output esperado: false

A exclusão dos Resource Groups é a forma mais eficiente de remover todos os recursos, pois elimina automaticamente VMs, VNets, discos, storage accounts, vaults (após remoção dos itens protegidos) e todos os demais recursos filhos. Confirme que ambos os grupos retornam false no comando de verificação.

Cenário​

Pré-requisitos​

Via Portal​

Via CLI​

Via Portal​

Via CLI​

Via Portal​

Via CLI​

Via CLI​

Via CLI​

Via CLI​

Fases do Laboratório​

Fase 1 — Criação dos Cofres de Backup​

Tarefa 1.1 — Criar o Recovery Services Vault​

Via Portal​

Via CLI​

Tarefa 1.2 — Criar o Azure Backup Vault​

Via Portal​

Via CLI​

Tarefa 1.3 — Validar a diferença de estado entre os cofres e tratar erro de configuração​

Via Portal​

Via CLI​

Tarefa 1.4 — Criar o Resource Group da região secundária​

Via Portal​

Via CLI​

Fase 2 — Políticas de Backup e Operações de Backup/Restore​

Tarefa 2.1 — Criar uma política de backup personalizada para VMs​

Via Portal​

Via CLI​

Tarefa 2.2 — Habilitar backup nas VMs com a política personalizada​

Via Portal​

Via CLI​

Tarefa 2.3 — Executar backup sob demanda e monitorar o progresso​

Via Portal​

Via CLI​

Tarefa 2.4 — Restaurar arquivos de uma VM a partir do ponto de recuperação​

Via Portal​

Via CLI​

Tarefa 2.5 — Criar política de backup para Blobs no Backup Vault​

Via Portal​

Via CLI​

Fase 3 — Azure Site Recovery e Failover​

Tarefa 3.1 — Verificar o estado atual da VM antes de habilitar a replicação​

Via Portal​

Via CLI​

Tarefa 3.2 — Configurar o Azure Site Recovery para replicar vm-web-01​

Via Portal​

Via CLI​

Tarefa 3.3 — Executar Test Failover para validar a replicação​

Via Portal​

Via CLI​

Tarefa 3.4 — Executar Failover completo para a região secundária​

Via Portal​

Via CLI​

Tarefa 3.5 — Reproteger a VM após o failover​

Via Portal​

Via CLI​

Fase 4 — Relatórios e Alertas para Backups​

Tarefa 4.1 — Configurar Diagnostic Settings no Recovery Services Vault​

Via Portal​

Via CLI​

Tarefa 4.2 — Acessar e interpretar Backup Reports​

Via Portal​

Via CLI​

Tarefa 4.3 — Configurar alertas para falhas de backup​

Via Portal​

Via CLI​

Tarefa 4.4 — Simular falha e validar o disparo do alerta​

Via Portal​

Via CLI​

Validação Final​

Cleanup do Ambiente​

Via Portal​

Via CLI​

Cenário

Pré-requisitos

Via Portal

Via CLI

Via Portal

Via CLI

Via Portal

Via CLI

Via CLI

Via CLI

Via CLI

Fases do Laboratório

Fase 1 — Criação dos Cofres de Backup

Tarefa 1.1 — Criar o Recovery Services Vault

Via Portal

Via CLI

Tarefa 1.2 — Criar o Azure Backup Vault

Via Portal

Via CLI

Tarefa 1.3 — Validar a diferença de estado entre os cofres e tratar erro de configuração

Via Portal

Via CLI

Tarefa 1.4 — Criar o Resource Group da região secundária

Via Portal

Via CLI

Fase 2 — Políticas de Backup e Operações de Backup/Restore

Tarefa 2.1 — Criar uma política de backup personalizada para VMs

Via Portal

Via CLI

Tarefa 2.2 — Habilitar backup nas VMs com a política personalizada

Via Portal

Via CLI

Tarefa 2.3 — Executar backup sob demanda e monitorar o progresso

Via Portal

Via CLI

Tarefa 2.4 — Restaurar arquivos de uma VM a partir do ponto de recuperação

Via Portal

Via CLI

Tarefa 2.5 — Criar política de backup para Blobs no Backup Vault

Via Portal

Via CLI

Fase 3 — Azure Site Recovery e Failover

Tarefa 3.1 — Verificar o estado atual da VM antes de habilitar a replicação

Via Portal

Via CLI

Tarefa 3.2 — Configurar o Azure Site Recovery para replicar vm-web-01

Via Portal

Via CLI

Tarefa 3.3 — Executar Test Failover para validar a replicação

Via Portal

Via CLI

Tarefa 3.4 — Executar Failover completo para a região secundária

Via Portal

Via CLI

Tarefa 3.5 — Reproteger a VM após o failover

Via Portal

Via CLI

Fase 4 — Relatórios e Alertas para Backups

Tarefa 4.1 — Configurar Diagnostic Settings no Recovery Services Vault

Via Portal

Via CLI

Tarefa 4.2 — Acessar e interpretar Backup Reports

Via Portal

Via CLI

Tarefa 4.3 — Configurar alertas para falhas de backup

Via Portal

Via CLI

Tarefa 4.4 — Simular falha e validar o disparo do alerta

Via Portal

Via CLI

Validação Final

Cleanup do Ambiente

Via Portal

Via CLI