Fundamentação Teórica: Perform Backup and Restore Operations by Using Azure Backup
1. Intuição Inicial
Nos tópicos anteriores, você criou o vault e configurou as políticas. Agora é hora de colocar tudo em operação: executar backups e restaurar dados quando necessário.
Pense no ciclo completo assim: o vault é o cofre, a política é o contrato de guarda, e as operações de backup e restore são os atos de depositar e retirar. Saber criar o cofre e assinar o contrato não é suficiente; você precisa saber como depositar na hora certa, como retirar no momento de emergência e quais opções de retirada existem.
Na prática, Azure Backup oferece dois caminhos de operação:
- Backup agendado: executado automaticamente conforme a política configurada. Você não precisa fazer nada após configurar o item protegido.
- Backup sob demanda (on-demand): executado manualmente fora do agendamento. Usado antes de mudanças críticas, para testes ou para cumprir requisitos pontuais.
A restauração, por sua vez, não é simplesmente "desfazer tudo". Existem múltiplas modalidades de restore, cada uma adequada para um cenário específico. Escolher a opção errada pode ser mais demorado ou pode sobrescrever dados que ainda estão bons.
2. Contexto
As operações de backup e restore estão no coração da jornada de proteção de dados. Todo o esforço de criar vaults e políticas existe para que, quando algo der errado, você possa restaurar com confiança.
O contexto para o AZ-104 é claro: você precisa saber não apenas que o Azure Backup existe, mas como habilitar proteção em itens específicos, disparar backups manuais, escolher o tipo correto de restore e monitorar jobs de backup e restore.
3. Construção dos Conceitos
3.1 Habilitando Proteção em um Item
Antes de qualquer backup acontecer, você precisa associar o recurso ao vault e a uma política. Esse processo é chamado de Enable Backup ou Configure Backup.
Para VMs Azure, o processo envolve:
- Selecionar o vault (que deve estar na mesma região da VM)
- Escolher a política de backup aplicável
- Confirmar a associação
A partir desse momento, o primeiro backup é agendado automaticamente. O primeiro backup é sempre um backup completo (full); os subsequentes são incrementais (com Enhanced Policy) ou seguem o comportamento legado.
Um comportamento importante: após habilitar proteção em uma VM, o Azure instala ou usa a extensão VMSnapshot (Windows) ou VMSnapshotLinux (Linux) na VM. Essa extensão coordena a captura consistente do snapshot com o sistema operacional. Se a extensão não puder ser instalada, o backup falha.
3.2 Tipos de Restore para VMs
Este é o conceito mais importante desta seção. Azure Backup oferece quatro modalidades de restore para VMs:
1. Restore the VM (Create New VM): cria uma nova VM a partir do ponto de recuperação. A VM original permanece intacta. Útil para comparar estados, testar restauração sem impactar produção ou recuperar em paralelo.
2. Restore Disks: restaura os discos da VM para uma conta de armazenamento, sem criar a VM automaticamente. Você pode então criar uma VM manualmente a partir dos discos, ou conectar os discos a uma VM existente. Mais flexível, mas exige etapas adicionais.
3. Replace Existing (In-Place Restore): substitui o disco OS ou discos de dados da VM existente com os dados do ponto de recuperação. A VM deve estar em execução para esta operação. Mais direto para correção de problemas, mas destrutivo: os dados atuais dos discos são substituídos.
4. Cross Region Restore (CRR): restaura para uma região secundária a partir de um ponto de recuperação replicado via GRS. Disponível apenas quando o vault usa GRS e CRR está habilitado. Usado em cenários de desastre regional.
3.3 File-Level Recovery (Item-Level Restore)
Além de restaurar a VM ou discos inteiros, o Azure Backup permite a recuperação de arquivos individuais sem restaurar a VM completa.
O processo é: o Azure monta o ponto de recuperação como um volume no seu computador (via script executável gerado no portal), você navega pelos arquivos e copia apenas o que precisa. O volume fica acessível por 12 horas por padrão (máximo de 24 horas).
Este método é drasticamente mais rápido quando você precisa de um arquivo específico, como um documento excluído acidentalmente ou uma configuração corrompida.
3.4 Backup On-Demand
Um backup on-demand é um backup executado imediatamente, fora do agendamento da política. Ele não substitui o próximo backup agendado; ambos serão executados.
A retenção de um backup on-demand é configurada no momento da execução. Você define por quantos dias aquele ponto específico deve ser retido, independentemente das regras da política.
Casos de uso comuns:
- Antes de aplicar um patch crítico ou atualização de sistema operacional
- Antes de migrar dados ou executar um script destrutivo
- Para criar um ponto de recuperação fora da janela de agendamento padrão
- Para cumprir um requisito de auditoria de ponto específico em uma data
3.5 Stop Protection
Azure Backup oferece duas formas de parar a proteção de um item:
Stop protection and retain data: para o agendamento de backups, mas mantém todos os pontos de recuperação existentes. Você continua sendo cobrado pelo armazenamento dos pontos. Útil quando vai descomissionar temporariamente um recurso, mas quer manter a capacidade de restaurar.
Stop protection and delete data: para o agendamento e agenda a exclusão de todos os pontos de recuperação. Com Soft Delete habilitado, os dados ficam retidos por 14 dias antes da exclusão definitiva.
4. Visão Estrutural
5. Funcionamento na Prática
Fluxo de um backup agendado para VM
O quiescing é o processo de colocar o sistema de arquivos em um estado consistente antes do snapshot. No Windows, isso é feito via VSS (Volume Shadow Copy Service). No Linux, é feito via scripts pré/pós configuráveis ou via freeze do sistema de arquivos. Sem quiescing, o snapshot pode capturar dados em estado inconsistente, o que pode causar corrupção ao restaurar.
Comportamentos pouco óbvios
O primeiro backup pode levar horas: o backup inicial é um full backup de todos os dados do disco, independentemente do tamanho. Uma VM com um disco de 500 GB levará muito mais tempo que uma com 30 GB. Os backups subsequentes são incrementais e muito mais rápidos.
O job de backup tem duas fases: a primeira fase cria o snapshot (rápida, geralmente minutos). A segunda fase transfere os dados para o vault (lenta, pode levar horas dependendo do tamanho e da largura de banda). O Instant Restore já fica disponível após a primeira fase.
Restore não é instantâneo da camada do vault: restaurar a partir do vault (não do snapshot) pode levar horas para VMs grandes. O restore a partir do Instant Restore Tier (snapshot) é muito mais rápido, mas só está disponível durante o período de retenção do snapshot (1 a 5 dias para Standard, 1 a 30 para Enhanced).
Replace Existing exige que a VM esteja em execução: este comportamento surpreende muitos. O Azure precisa da VM em execução para coordenar a substituição do disco com segurança.
6. Formas de Implementação
6.1 Portal Azure
Habilitando proteção em uma VM:
- Acesse o Recovery Services Vault
- Clique em "Backup"
- Em "Where is your workload running?": selecione "Azure"
- Em "What do you want to backup?": selecione "Virtual machine"
- Clique em "Backup"
- Selecione a política de backup
- Selecione as VMs a proteger
- Clique em "Enable Backup"
Executando backup on-demand:
- No vault, acesse "Backup Items" > "Azure Virtual Machine"
- Selecione a VM desejada
- Clique em "Backup Now"
- Defina a data de retenção do ponto criado
- Confirme
Executando restore de VM (Create New VM):
- No vault, acesse "Backup Items" > "Azure Virtual Machine"
- Selecione a VM
- Clique em "Restore VM"
- Selecione o ponto de recuperação
- Escolha "Create new" como tipo de restore
- Configure: nome da nova VM, Resource Group, Virtual Network, Subnet, conta de armazenamento de staging
- Clique em "Restore"
Executando File-Level Recovery:
- No vault, acesse "Backup Items" > "Azure Virtual Machine"
- Selecione a VM
- Clique em "File Recovery"
- Selecione o ponto de recuperação
- Faça download do script executável gerado
- Execute o script na VM de destino (Windows: .exe, Linux: .sh)
- O script monta o disco do backup como volume local
- Copie os arquivos necessários
- Clique em "Unmount Disks" no portal para desmontagem
6.2 Azure CLI
Habilitar proteção em uma VM:
# Obter o vault
VAULT_NAME="rsv-prod-brazilsouth"
RG="rg-backup-prod"
VM_NAME="vm-producao-01"
VM_RG="rg-app-prod"
POLICY_NAME="policy-vm-prod-daily"
# Habilitar backup na VM
az backup protection enable-for-vm \
--resource-group $RG \
--vault-name $VAULT_NAME \
--vm $VM_NAME \
--policy-name $POLICY_NAME
Executar backup on-demand:
# Disparar backup on-demand
az backup protection backup-now \
--resource-group $RG \
--vault-name $VAULT_NAME \
--container-name "IaasVMContainer;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--item-name "VM;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--backup-management-type AzureIaasVM \
--retain-until "31-12-2025"
Listar pontos de recuperação:
az backup recoverypoint list \
--resource-group $RG \
--vault-name $VAULT_NAME \
--container-name "IaasVMContainer;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--item-name "VM;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--backup-management-type AzureIaasVM \
--workload-type VM \
--output table
Restaurar discos (Restore Disks):
# Obter ID do ponto de recuperação
RECOVERY_POINT_ID=$(az backup recoverypoint list \
--resource-group $RG \
--vault-name $VAULT_NAME \
--container-name "IaasVMContainer;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--item-name "VM;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--backup-management-type AzureIaasVM \
--workload-type VM \
--query "[0].name" -o tsv)
# Executar restore dos discos para storage account
az backup restore restore-disks \
--resource-group $RG \
--vault-name $VAULT_NAME \
--container-name "IaasVMContainer;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--item-name "VM;iaasvmcontainerv2;$VM_RG;$VM_NAME" \
--rp-name $RECOVERY_POINT_ID \
--storage-account "stagebackuprestore" \
--restore-to-staging-storage-account true
Monitorar jobs:
# Listar jobs recentes
az backup job list \
--resource-group $RG \
--vault-name $VAULT_NAME \
--output table
# Verificar detalhes de um job específico
az backup job show \
--resource-group $RG \
--vault-name $VAULT_NAME \
--name <job-id>
6.3 Azure PowerShell
Habilitar proteção:
$vault = Get-AzRecoveryServicesVault `
-ResourceGroupName "rg-backup-prod" `
-Name "rsv-prod-brazilsouth"
Set-AzRecoveryServicesVaultContext -Vault $vault
$policy = Get-AzRecoveryServicesBackupProtectionPolicy `
-Name "policy-vm-prod-daily"
$vm = Get-AzVM `
-ResourceGroupName "rg-app-prod" `
-Name "vm-producao-01"
Enable-AzRecoveryServicesBackupProtection `
-ResourceGroupName "rg-app-prod" `
-Name "vm-producao-01" `
-Policy $policy
Backup on-demand:
$container = Get-AzRecoveryServicesBackupContainer `
-ContainerType AzureVM `
-FriendlyName "vm-producao-01"
$item = Get-AzRecoveryServicesBackupItem `
-Container $container `
-WorkloadType AzureVM
Backup-AzRecoveryServicesBackupItem `
-Item $item `
-ExpiryDateTimeUTC (Get-Date).AddDays(30)
Listar pontos e restaurar:
# Listar pontos de recuperação
$rps = Get-AzRecoveryServicesBackupRecoveryPoint `
-Item $item
# Selecionar o mais recente
$rp = $rps[0]
# Restaurar discos para storage account
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName "rg-restore-staging" `
-Name "stagebackuprestore"
Restore-AzRecoveryServicesBackupItem `
-RecoveryPoint $rp `
-StorageAccountName $storageAccount.StorageAccountName `
-StorageAccountResourceGroupName $storageAccount.ResourceGroupName `
-RestoreOnlyOSDisk $false
7. Controle e Segurança
RBAC para operações de backup e restore
| Operação | Role mínima necessária |
|---|---|
| Habilitar proteção em VM | Backup Contributor + VM Contributor |
| Executar backup on-demand | Backup Operator |
| Restaurar VM (Create New) | Backup Operator + permissão no RG destino |
| Restaurar discos | Backup Operator + Storage Contributor no storage de staging |
| Replace Existing | Backup Operator + VM Contributor na VM |
| File Recovery | Backup Operator |
| Stop protection | Backup Contributor |
Multi-user Authorization (MUA)
O Azure Backup suporta Multi-user Authorization: operações críticas como desabilitar soft delete, parar proteção com exclusão de dados ou modificar configurações de segurança do vault podem exigir aprovação de um segundo administrador.
Para habilitar MUA, é necessário um Resource Guard configurado em uma subscription separada, gerenciado por um time de segurança diferente do time de backup. Isso implementa segregação de funções para operações destrutivas.
Proteção contra restauração não autorizada
O restore cria recursos reais (VMs, discos, arquivos) que consomem custo e podem expor dados sensíveis. Por isso:
- Limite o acesso à role Backup Operator apenas a quem realmente precisa executar restores
- Monitore jobs de restore via Azure Monitor e configure alertas para qualquer operação de restore
- Use Resource Locks nos vaults de produção para evitar exclusão acidental
8. Tomada de Decisão
Qual tipo de restore usar
| Cenário | Modalidade de Restore | Motivo |
|---|---|---|
| VM corrompida, precisa restaurar tudo sem perder a original | Create New VM | Cria VM paralela; original intacta para comparação |
| Arquivo individual excluído acidentalmente | File-Level Recovery | Muito mais rápido; não precisa restaurar VM inteira |
| Disco OS corrompido, VM existe mas não inicializa | Replace Existing | Substitui disco da VM existente; mais direto |
| Migração ou reconfiguração da VM antes de restaurar | Restore Disks | Mais controle; permite reconfigurar VM manualmente |
| Região primária indisponível por desastre | Cross Region Restore | Único método disponível para restaurar na região secundária |
| Precisa testar restore sem impactar produção | Create New VM | Restauração em ambiente isolado |
Backup agendado vs on-demand
| Situação | Abordagem | Motivo |
|---|---|---|
| Manutenção planejada ou deploy crítico | On-demand | Garante ponto de recuperação no momento exato antes da mudança |
| Proteção contínua do workload | Agendado | Automático, consistente, sem intervenção manual |
| Auditoria ou compliance em data específica | On-demand | Cria ponto com retenção específica para aquela data |
| Janela de manutenção fora do horário do agendamento | On-demand | Complementa o agendamento padrão |
9. Boas Práticas
Sempre fazer backup on-demand antes de mudanças significativas: patches de segurança críticos, atualizações de aplicação, alterações de configuração ou migração são momentos que exigem um ponto de recuperação atual, independentemente do agendamento.
Testar restore regularmente em ambiente isolado: backups não testados são de valor desconhecido. Programe testes de restore trimestrais usando "Create New VM" em um Resource Group de sandbox, verificando integridade dos dados e tempo de execução.
Usar File-Level Recovery para recuperações pontuais: recuperar um único arquivo via File Recovery é ordens de magnitude mais rápido que restaurar uma VM inteira. Treine a equipe para usar esse caminho antes de acionar um restore completo.
Monitorar o primeiro backup de cada novo item: o primeiro backup é o mais crítico e o mais demorado. Verifique ativamente o job do primeiro backup ao habilitar proteção em novos recursos.
Documentar o RTO real: o RTO teórico (baseado em estimativas) frequentemente difere do RTO real (baseado em testes). Execute um restore real e meça o tempo para ter um RTO documentado e confiável.
Usar staging Resource Group separado para restores: restaurações de discos produzem artefatos (VMs, discos, arquivos de configuração) que precisam ser gerenciados. Use um Resource Group dedicado para staging de restores, com limpeza automática após validação.
10. Erros Comuns
Erro: esperar que o restore seja instantâneo Por que acontece: confusão entre a velocidade do Instant Restore (snapshot) e do restore do vault. Como evitar: entenda que o Instant Restore está disponível apenas dentro do período de retenção de snapshots (1 a 5 dias para Standard). Fora desse período, o restore vem do vault e pode levar horas.
Erro: usar Replace Existing quando a VM está desligada Por que acontece: o operador desliga a VM antes de restaurar, achando que é mais seguro. Como evitar: lembre que Replace Existing exige VM em execução. Para VM desligada, use Restore Disks ou Create New VM.
Erro: não configurar storage account de staging antes do restore de discos Por que acontece: o restore de discos exige uma storage account na mesma região. Operadores esquecem de criar o storage antecipadamente. Como evitar: inclua a criação do storage de staging no playbook de restauração. Idealmente, mantenha um storage account de staging dedicado, sempre disponível.
Erro: confundir File Recovery com restore completo para arquivos grandes Por que acontece: File Recovery monta o disco como volume; para arquivos muito grandes (dezenas de GB), copiar pela rede pode ser tão lento quanto um restore completo. Como evitar: para recuperação de arquivos grandes (acima de alguns GB), avalie se Restore Disks seria mais eficiente.
Erro: não verificar a integridade após o restore Por que acontece: o operador assume que "restore concluído" significa "dados íntegros". Como evitar: sempre valide o restore: inicie a VM, verifique serviços, confirme integridade de dados críticos antes de declarar o restore bem-sucedido.
Erro: fazer restore direto em produção sem teste em paralelo Por que acontece: pressão por velocidade em situações de incidente. Como evitar: use "Create New VM" para validar o ponto de recuperação em paralelo antes de executar Replace Existing ou descomissionar a VM atual.
11. Operação e Manutenção
Monitorando jobs de backup
No portal, acesse o vault e navegue para Backup Jobs. Os estados possíveis:
| Status do Job | Significado | Ação necessária |
|---|---|---|
| Completed | Job finalizado com sucesso | Nenhuma |
| Completed with warnings | Job concluído, mas com avisos (ex: arquivo aberto não incluído) | Investigar aviso |
| In Progress | Job em execução | Aguardar; monitorar duração |
| Failed | Job falhou completamente | Investigar causa; verificar logs |
| Cancelled | Job cancelado manualmente | Verificar se foi intencional |
Causas comuns de falha de backup
| Causa | Sintoma | Resolução |
|---|---|---|
| Extensão VMSnapshot desatualizada ou corrompida | Falha na fase de snapshot | Re-instalar extensão no portal |
| VM sem conectividade com endpoint do Azure Backup | Timeout durante transferência | Verificar NSG, UDR e Private Endpoints |
| Disco excedendo limite suportado | Falha no backup de disco | Verificar tamanho máximo suportado (32 TB) |
| Conta de storage de staging excluída | Falha em restore de disco | Recriar storage account de staging |
| Permissões insuficientes | Erro 403 nos logs | Revisar RBAC do operador e da extensão |
Limites operacionais importantes
| Limite | Valor |
|---|---|
| Tamanho máximo de disco para backup de VM | 32 TB |
| Pontos de recuperação por item protegido (VMs) | 9999 |
| Janela de Instant Restore (Standard) | 1 a 5 dias |
| Janela de Instant Restore (Enhanced) | 1 a 30 dias |
| Duração do volume montado no File Recovery | 12 horas (padrão), máximo 24h |
| Máximo de backups on-demand por dia por item | 9 |
| Tempo de retenção mínimo para on-demand | 1 dia |
12. Integração e Automação
Automação de backup on-demand antes de deploys
Um padrão comum é integrar backup on-demand em pipelines CI/CD, garantindo que um ponto de recuperação seja criado antes de qualquer deploy em produção:
Alertas automatizados via Azure Monitor
Configure alertas para falhas de backup sem precisar monitorar manualmente:
# Criar regra de alerta para falhas de backup
az monitor alert create \
--name "alert-backup-failure" \
--resource-group rg-backup-prod \
--target /subscriptions/{sub}/resourceGroups/rg-backup-prod/providers/Microsoft.RecoveryServices/vaults/rsv-prod-brazilsouth \
--condition "category=Backup and level=Error" \
--action-group /subscriptions/{sub}/resourceGroups/rg-backup-prod/providers/microsoft.insights/actionGroups/ag-backup-ops
Runbooks para restore automatizado
Para cenários de DR (Disaster Recovery) com RTO agressivo, é possível criar Azure Automation Runbooks que executam o restore automaticamente quando acionados por um alerta ou webhook. O runbook chama as APIs do Azure Backup via PowerShell para:
- Identificar o ponto de recuperação mais recente
- Disparar restore de discos para staging
- Criar nova VM a partir dos discos
- Executar scripts de validação pós-restore
- Redirecionar tráfego (via Azure Load Balancer ou DNS) para a nova VM
13. Resumo Final
O que são as operações de backup e restore: conjunto de ações que habilitam proteção em recursos Azure, executam backups agendados e manuais, e recuperam dados a partir de pontos de restauração armazenados no vault.
Pontos essenciais:
- Habilitar proteção associa o recurso ao vault e à política; o primeiro backup é sempre full e pode levar horas
- Backup on-demand cria um ponto de recuperação imediato com retenção definida na execução; não cancela o próximo backup agendado
- Existem quatro modalidades de restore para VMs: Create New VM, Restore Disks, Replace Existing e Cross Region Restore
- File-Level Recovery monta o ponto de recuperação como volume local por até 24 horas para recuperação de arquivos individuais
- Instant Restore usa o snapshot tier para restauração rápida; fora do período de snapshot, o restore vem do vault e é mais lento
Diferenças críticas entre modalidades de restore:
| Modalidade | VM original afetada | VM precisa estar ligada | Velocidade |
|---|---|---|---|
| Create New VM | Não | Indiferente | Moderada |
| Restore Disks | Não | Indiferente | Moderada |
| Replace Existing | Sim (discos substituídos) | Sim, obrigatório | Mais direta |
| Cross Region Restore | Não | Indiferente | Mais lenta (dados de região secundária) |
| File Recovery | Não | Indiferente | Rápida para arquivos pequenos |
O que precisa ser lembrado para o AZ-104:
- Replace Existing exige VM em execução
- File Recovery monta o volume por no máximo 24 horas
- Cross Region Restore requer vault com GRS e CRR habilitado
- O primeiro backup é sempre full; os subsequentes são incrementais (Enhanced Policy)
- Máximo de 9 backups on-demand por dia por item protegido
- Backup on-demand não substitui o próximo backup agendado; ambos ocorrem
- Instant Restore só está disponível dentro do período de retenção de snapshots configurado na política