Fundamentação Teórica: Create and Configure a Backup Policy

1. Intuição Inicial

Nos tópicos anteriores, você criou o cofre (Recovery Services Vault ou Backup Vault). O cofre é o contêiner, mas ele sozinho não faz nada. Você precisa dizer a ele quando fazer backup, com que frequência e por quanto tempo guardar os dados. Isso é exatamente o que uma Backup Policy define.

A analogia mais direta: pense em um serviço de fotocópia de documentos importantes. Você contrata o serviço (cria o vault), mas precisa assinar um contrato especificando "tire uma cópia toda segunda-feira, guarde as cópias semanais por 1 mês, as mensais por 1 ano e as anuais por 5 anos". Esse contrato é a Backup Policy.

Na prática, a Backup Policy responde a três perguntas fundamentais:

Quando executar o backup? (agendamento)
O que capturar em cada execução? (tipo de ponto de recuperação)
Por quanto tempo manter cada ponto? (retenção)

2. Contexto

A Backup Policy existe entre o vault e os itens protegidos. Ela é o elo que transforma um vault vazio em um sistema de proteção ativo.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Uma política é criada dentro de um vault e pode ser aplicada a múltiplos itens. Um vault pode ter várias políticas. Cada item protegido, porém, usa apenas uma política por vez.

A política existe porque diferentes workloads têm necessidades radicalmente diferentes:

Um banco de dados de produção pode exigir backup a cada hora com retenção de 7 anos
Uma VM de desenvolvimento pode precisar de backup diário com retenção de 7 dias
Um servidor de arquivos pode exigir backup diário, semanal e mensal com retenções escalonadas

Sem políticas, você teria que configurar cada item individualmente. Com políticas, você configura uma vez e aplica a quantos itens precisar.

3. Construção dos Conceitos

3.1 Recovery Point Objective (RPO) e Recovery Time Objective (RTO)

Antes de configurar uma política, você precisa entender dois conceitos que determinam as escolhas de agendamento.

RPO (Recovery Point Objective): quanto de perda de dados é aceitável? Se seu backup é diário, o pior cenário é perder 24 horas de dados. Se for por hora, perde no máximo 1 hora. O RPO define a frequência mínima de backup.

RTO (Recovery Time Objective): quanto tempo pode levar para restaurar e voltar à operação? Isso não é configurado na política diretamente, mas a frequência e o tipo de backup afetam o RTO, pois backups mais frequentes geralmente resultam em pontos de restauração menores e mais rápidos.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 Tipos de Backup

Full Backup: cópia completa de todos os dados do recurso em um momento específico. Consome mais espaço e tempo, mas a restauração é mais simples.

Incremental Backup: copia apenas os dados que mudaram desde o último backup (full ou incremental). Mais rápido e econômico, mas a restauração é mais complexa porque precisa encadear múltiplos pontos.

O Azure Backup usa backup incremental para VMs por padrão desde 2020 (Enhanced Policy). O primeiro backup sempre é full; os subsequentes são incrementais. O usuário não precisa gerenciar essa distinção; a plataforma faz automaticamente.

Snapshot: captura do estado de um disco em um momento específico, sem necessidade de copiar dados para fora do recurso. Muito rápido, mas limitado em retenção. Usado pelo backup de Azure Disks e pela camada operacional do Backup Vault.

3.3 Estrutura de uma Backup Policy para VMs (Recovery Services Vault)

Uma política para VMs tem os seguintes elementos configuráveis:

Frequência de backup (Backup Schedule):

Diária: um backup por dia, no horário definido
Por hora (somente Enhanced Policy): backups a cada 1, 2, 4, 6, 8 ou 12 horas, dentro de uma janela de tempo configurável

Janela de backup (Backup Window): horário de início e duração da janela em que os backups podem ser executados. Relevante principalmente para políticas horárias.

Instant Restore: número de snapshots instantâneos mantidos localmente para restauração rápida sem precisar acessar o vault. Configurável de 1 a 5 dias.

Retenção de pontos de recuperação: define por quanto tempo cada tipo de ponto é mantido:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.4 Standard Policy vs Enhanced Policy (VMs)

Esta é uma distinção crítica para o AZ-104:

Característica	Standard Policy	Enhanced Policy
Frequência mínima	Diária	Por hora (mínimo 1h)
RPO mínimo	24 horas	1 hora
Instant Restore	1 a 5 dias	1 a 30 dias
Suporte a Trusted Launch VMs	Não	Sim
Suporte a Ultra Disks	Não	Sim
Custo	Menor	Maior
Tipo de backup	Incremental (legado: full)	Incremental sempre

Ponto de atenção: uma vez que um item protegido usa Enhanced Policy, não é possível fazer downgrade para Standard Policy sem remover a proteção e re-configurar.

3.5 Políticas para outros workloads

Cada workload tem suas próprias opções de política. As principais diferenças:

Workload	Vault	Frequência	Retenção máxima
Azure VM	Recovery Services Vault	Diária ou horária	99 anos
SQL Server em VM	Recovery Services Vault	Log: a cada 15 min; Full: semanal	99 anos
Azure Files	Recovery Services Vault	Diária	10 anos
Azure Disk	Backup Vault	A cada 1h, 4h, 6h, 8h ou 12h, ou diária	30 dias (Vault Tier)
Azure Blob	Backup Vault	Contínuo (retenção operacional)	360 dias
PostgreSQL Flexible	Backup Vault	Semanal	10 anos

4. Visão Estrutural

Como uma política se encaixa no fluxo completo de proteção:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Como os pontos de retenção se encadeiam

Um aspecto pouco óbvio: os pontos de retenção semanal, mensal e anual não são backups separados. Eles são promovidos a partir dos backups diários que coincidem com os critérios.

Exemplo concreto: você configura uma política assim:

Backup diário: toda segunda a domingo, retido por 30 dias
Backup semanal: toda segunda-feira, retido por 12 semanas
Backup mensal: primeiro domingo de cada mês, retido por 12 meses

O backup executado na segunda-feira será o mesmo ponto de recuperação marcado como "diário" e "semanal". O backup do primeiro domingo de cada mês será marcado como "diário", "semanal" e "mensal". Um único job, múltiplos rótulos de retenção.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Isso significa que o ponto marcado como mensal será retido pelo período mais longo dentre todos os rótulos aplicados a ele.

Instant Restore (Snapshot Tier)

O Instant Restore é uma camada de snapshots locais criados antes dos dados serem transferidos para o vault. Enquanto o snapshot existe, a restauração é muito mais rápida (minutos em vez de horas), porque os dados estão no mesmo storage que o disco, sem precisar de download do vault.

Quando o período de Instant Restore expira, o snapshot é deletado, mas o ponto de recuperação ainda existe no vault (para retenção mais longa). A restauração a partir do vault é mais lenta.

6. Formas de Implementação

6.1 Portal Azure

Quando usar: criação inicial, validação visual de configurações, ambientes de aprendizado.

Criando uma política para VM (Standard) no Recovery Services Vault:

Acesse o Recovery Services Vault
Em "Backup policies", clique em "Add"
Selecione "Azure Virtual Machine"
Escolha o tipo: Standard ou Enhanced
Configure:
- Policy name: nome descritivo, ex: policy-vm-prod-daily
- Backup schedule: frequência (Daily ou Hourly) e horário (ex: 23:00 UTC)
- Instant Restore: número de dias para manter snapshots (1 a 5 para Standard)
- Retention range:
  - Daily: quantos dias (ex: 30)
  - Weekly: qual dia da semana e quantas semanas (ex: domingo, 12 semanas)
  - Monthly: qual semana/dia do mês e quantos meses (ex: primeiro domingo, 12 meses)
  - Yearly: qual mês e dia, e quantos anos (ex: janeiro, primeiro domingo, 5 anos)
Clique em "Create"

6.2 Azure CLI

Quando usar: automação, pipelines, criação em massa.

Para VMs no Recovery Services Vault, as políticas são definidas via JSON. Primeiro, obtenha o template padrão:

# Obter template de política padrão para VMs
az backup policy get-default-for-vm \
  --resource-group rg-backup-prod \
  --vault-name rsv-prod-brazilsouth

O retorno é um JSON com a estrutura da política. Salve como policy.json e edite conforme necessário. Em seguida, crie a política:

# Criar política a partir do arquivo JSON
az backup policy create \
  --resource-group rg-backup-prod \
  --vault-name rsv-prod-brazilsouth \
  --name policy-vm-prod-daily \
  --policy @policy.json \
  --backup-management-type AzureIaasVM

Para listar políticas existentes:

az backup policy list \
  --resource-group rg-backup-prod \
  --vault-name rsv-prod-brazilsouth

Para atualizar uma política existente:

az backup policy set \
  --resource-group rg-backup-prod \
  --vault-name rsv-prod-brazilsouth \
  --name policy-vm-prod-daily \
  --policy @policy-updated.json

Exemplo de estrutura JSON para política de VM (Standard):

{
  "eTag": null,
  "location": null,
  "name": "policy-vm-prod-daily",
  "properties": {
    "backupManagementType": "AzureIaasVM",
    "instantRpRetentionRangeInDays": 2,
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicy",
      "scheduleRunFrequency": "Daily",
      "scheduleRunTimes": ["2024-01-01T23:00:00Z"]
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {
        "retentionTimes": ["2024-01-01T23:00:00Z"],
        "retentionDuration": {
          "count": 30,
          "durationType": "Days"
        }
      },
      "weeklySchedule": {
        "daysOfTheWeek": ["Sunday"],
        "retentionTimes": ["2024-01-01T23:00:00Z"],
        "retentionDuration": {
          "count": 12,
          "durationType": "Weeks"
        }
      },
      "monthlySchedule": {
        "retentionScheduleFormatType": "Weekly",
        "retentionScheduleWeekly": {
          "daysOfTheWeek": ["Sunday"],
          "weeksOfTheMonth": ["First"]
        },
        "retentionTimes": ["2024-01-01T23:00:00Z"],
        "retentionDuration": {
          "count": 12,
          "durationType": "Months"
        }
      }
    }
  }
}

6.3 Azure PowerShell

Quando usar: ambientes Windows corporativos, automação com scripts existentes.

# Obter o vault
$vault = Get-AzRecoveryServicesVault `
  -ResourceGroupName "rg-backup-prod" `
  -Name "rsv-prod-brazilsouth"

# Definir contexto do vault
Set-AzRecoveryServicesVaultContext -Vault $vault

# Obter política padrão para VMs
$defaultPolicy = Get-AzRecoveryServicesBackupProtectionPolicy `
  -Name "DefaultPolicy"

# Criar agendamento
$schedulePolicy = Get-AzRecoveryServicesBackupSchedulePolicyObject `
  -WorkloadType AzureVM

$schedulePolicy.ScheduleRunFrequency = "Daily"
$schedulePolicy.ScheduleRunTimes[0] = (Get-Date "2024-01-01 23:00:00Z").ToUniversalTime()

# Criar retenção
$retentionPolicy = Get-AzRecoveryServicesBackupRetentionPolicyObject `
  -WorkloadType AzureVM

$retentionPolicy.DailySchedule.DurationCountInDays = 30
$retentionPolicy.IsWeeklyScheduleEnabled = $true
$retentionPolicy.WeeklySchedule.DaysOfTheWeek = @("Sunday")
$retentionPolicy.WeeklySchedule.DurationCountInWeeks = 12

# Criar a política
New-AzRecoveryServicesBackupProtectionPolicy `
  -Name "policy-vm-prod-daily" `
  -WorkloadType AzureVM `
  -RetentionPolicy $retentionPolicy `
  -SchedulePolicy $schedulePolicy

6.4 ARM Template

Quando usar: IaC versionado, pipelines de deployment corporativo.

{
  "type": "Microsoft.RecoveryServices/vaults/backupPolicies",
  "apiVersion": "2023-01-01",
  "name": "[concat(parameters('vaultName'), '/policy-vm-prod-daily')]",
  "dependsOn": [
    "[resourceId('Microsoft.RecoveryServices/vaults', parameters('vaultName'))]"
  ],
  "properties": {
    "backupManagementType": "AzureIaasVM",
    "instantRpRetentionRangeInDays": 2,
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicy",
      "scheduleRunFrequency": "Daily",
      "scheduleRunTimes": ["2024-01-01T23:00:00Z"]
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {
        "retentionTimes": ["2024-01-01T23:00:00Z"],
        "retentionDuration": {
          "count": 30,
          "durationType": "Days"
        }
      }
    }
  }
}

7. Controle e Segurança

Quem pode criar e modificar políticas

A gestão de políticas segue o RBAC do vault:

Role	Pode criar política	Pode modificar política	Pode associar itens
Backup Contributor	Sim	Sim	Sim
Backup Operator	Não	Não	Sim (com política existente)
Backup Reader	Não	Não	Não
Owner / Contributor	Sim	Sim	Sim

Impacto de alterar uma política existente

Modificar uma política existente afeta imediatamente todos os itens protegidos que a utilizam. Isso inclui:

Mudança de horário de backup: próximo backup será no novo horário
Redução de retenção: pontos de recuperação que excedem o novo limite são marcados para exclusão e removidos no próximo ciclo de limpeza
Aumento de retenção: pontos existentes não são retroativamente estendidos; somente novos pontos seguem a nova retenção

Este comportamento de redução é crítico: se você reduzir a retenção de 365 dias para 30 dias, pontos com mais de 30 dias serão excluídos. Não há como recuperá-los se o soft delete não estiver habilitado para aquele estado.

8. Tomada de Decisão

Escolha entre Standard e Enhanced Policy para VMs

Situação	Melhor escolha	Motivo
VM de produção com banco de dados transacional	Enhanced Policy	RPO de 1 hora; reduz perda de dados
VM de desenvolvimento ou teste	Standard Policy	Backup diário suficiente; menor custo
VM com Ultra Disks ou Trusted Launch	Enhanced Policy	Standard não suporta esses recursos
Conformidade regulatória com RPO < 4h	Enhanced Policy	Standard só oferece backup diário
Orçamento restrito em workloads não críticos	Standard Policy	Custo significativamente menor

Configuração de retenção por criticidade

Criticidade	Diário	Semanal	Mensal	Anual
Produção crítica (financeiro, saúde)	30 dias	52 semanas	60 meses	10 anos
Produção padrão	30 dias	12 semanas	12 meses	5 anos
Staging/Homologação	14 dias	4 semanas	Não necessário	Não necessário
Desenvolvimento	7 dias	Não necessário	Não necessário	Não necessário

Instant Restore: quantos dias configurar

Cenário	Recomendação	Motivo
VMs críticas com restauração rápida obrigatória	5 dias	Máximo para Standard; restauração em minutos
VMs padrão de produção	2 a 3 dias	Equilíbrio entre custo de snapshot e velocidade
VMs de dev/test	1 dia	Minimiza custo de armazenamento de snapshot

9. Boas Práticas

Nomeclatura descritiva: use nomes como policy-vm-prod-daily-30d ou policy-vm-dev-7d para indicar workload, ambiente, frequência e retenção.

Criar políticas por camada de criticidade: tenha políticas pré-definidas para Tier 1 (crítico), Tier 2 (padrão) e Tier 3 (dev/test). Isso reduz proliferação de políticas únicas por item.

Alinhar horário de backup com janelas de manutenção: programe backups para horários de menor carga, geralmente madrugada no fuso horário do negócio. Lembre que o horário no Azure é UTC.

Nunca modificar políticas de produção sem avaliação de impacto: qualquer redução de retenção é irreversível. Documente e aprove alterações antes de executar.

Usar políticas separadas para SQL em VMs: o SQL Server em VMs requer políticas específicas com backup de log transacional (a cada 15 a 60 minutos) para garantir RPO próximo de zero para bancos de dados.

Revisar periodicamente: políticas criadas há anos podem não refletir mais os requisitos do negócio. Inclua revisão anual de políticas no processo de governança.

10. Erros Comuns

Erro: configurar horário de backup em horário de pico Por que acontece: o operador configura 12:00 sem considerar o impacto no desempenho. Como evitar: sempre agende backups na madrugada (UTC); verifique o fuso horário antes de configurar.

Erro: reduzir retenção sem perceber que exclui pontos existentes Por que acontece: o operador assume que a mudança afeta apenas novos backups. Como evitar: leia o aviso de impacto apresentado pelo portal antes de confirmar a alteração. Documente a janela de retenção atual antes de modificar.

Erro: usar uma única política para todos os workloads Por que acontece: simplificação excessiva para reduzir gestão. Como evitar: segmente por criticidade. Uma única política com retenção de 5 anos para dev/test gera custo desnecessário; uma política de 7 dias para produção crítica gera risco.

Erro: não configurar retenção semanal/mensal/anual para ambientes de produção Por que acontece: o operador configura apenas retenção diária. Como evitar: entenda que a retenção diária por 30 dias significa que se o dado foi corrompido há 31 dias e só foi descoberto hoje, não há recuperação. Retenções longas protegem contra corrupção lenta.

Erro: esquecer que o horário no Azure é UTC Por que acontece: o operador configura 23:00 pensando no horário local, mas o Azure executa em UTC. Como evitar: sempre converta o horário local para UTC antes de configurar. Para o Brasil (UTC-3), 23:00 local = 02:00 UTC do dia seguinte.

11. Operação e Manutenção

Monitorando compliance de políticas

No Backup Center, a visão de "Backup Instances" mostra o status de cada item protegido. Os principais estados:

Status	Significado
Protection configured	Backup ativo e funcionando normalmente
Protection stopped (retain data)	Backup pausado, dados retidos
Protection stopped (delete data)	Backup pausado, dados sendo excluídos
Initial backup pending	Primeiro backup ainda não executado
Warning	Backup executando com avisos (ex: snapshot parcial)
Critical	Backup falhando sistematicamente

Alterar política de um item protegido

É possível migrar um item de uma política para outra sem interromper a proteção:

# Alterar política de uma VM específica
az backup item set-policy \
  --resource-group rg-backup-prod \
  --vault-name rsv-prod-brazilsouth \
  --name AzureIaasVMIaasVMContainerV2;vm-producao \
  --policy-name policy-vm-prod-enhanced \
  --backup-management-type AzureIaasVM \
  --workload-type VM

Limites importantes

Limite	Valor
Políticas por vault (Recovery Services)	200
Políticas por vault (Backup Vault)	100
Itens protegidos por política	Sem limite documentado
Horários de backup por política (Standard)	1 por dia
Horários de backup por política (Enhanced)	Múltiplos (depende do intervalo)
Retenção máxima diária	9999 dias
Retenção máxima anual	99 anos

12. Integração e Automação

Azure Policy para aplicar Backup Policies automaticamente

Você pode usar Azure Policy para garantir que novas VMs sejam automaticamente protegidas com uma política específica:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A política integrada relevante é: Configure backup on VMs without a given tag to an existing recovery services vault in the same location.

Automação de criação de políticas com Terraform

resource "azurerm_backup_policy_vm" "prod" {
  name                = "policy-vm-prod-daily"
  resource_group_name = azurerm_resource_group.backup.name
  recovery_vault_name = azurerm_recovery_services_vault.main.name

  backup {
    frequency = "Daily"
    time      = "23:00"
  }

  retention_daily {
    count = 30
  }

  retention_weekly {
    count    = 12
    weekdays = ["Sunday"]
  }

  retention_monthly {
    count    = 12
    weekdays = ["Sunday"]
    weeks    = ["First"]
  }

  retention_yearly {
    count    = 5
    weekdays = ["Sunday"]
    weeks    = ["First"]
    months   = ["January"]
  }
}

13. Resumo Final

O que é: conjunto de regras que define frequência de backup, configuração de snapshots instantâneos e retenção de pontos de recuperação, aplicado a itens protegidos dentro de um vault.

Pontos essenciais:

Uma política responde a três perguntas: quando fazer backup, o que capturar e por quanto tempo reter
Políticas são criadas dentro de um vault e podem ser aplicadas a múltiplos itens
Cada item protegido usa apenas uma política por vez
Pontos de retenção semanal/mensal/anual são promovidos a partir de backups diários existentes, não são jobs separados
Instant Restore mantém snapshots locais para restauração rápida pelo período configurado (1 a 5 dias no Standard, 1 a 30 no Enhanced)
Reduzir a retenção de uma política exclui imediatamente pontos que excedem o novo limite

Diferenças críticas:

Aspecto	Standard Policy	Enhanced Policy
Frequência mínima	Diária	Horária (mínimo 1h)
Instant Restore	Até 5 dias	Até 30 dias
Suporte Ultra Disk / Trusted Launch	Não	Sim
Downgrade possível	N/A	Não permite voltar para Standard

O que precisa ser lembrado para o AZ-104:

O horário de backup é configurado em UTC; sempre converta do fuso local
Modificar uma política existente impacta todos os itens que a utilizam imediatamente
Redução de retenção não é reversível para pontos já excluídos
Enhanced Policy não pode ser rebaixada para Standard sem remover e re-configurar proteção
SQL Server em VMs exige política específica com backup de log transacional para RPO baixo
Backup de Azure Blobs usa retenção operacional contínua, sem agendamento de job tradicional

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 Recovery Point Objective (RPO) e Recovery Time Objective (RTO)​

3.2 Tipos de Backup​

3.3 Estrutura de uma Backup Policy para VMs (Recovery Services Vault)​

3.4 Standard Policy vs Enhanced Policy (VMs)​

3.5 Políticas para outros workloads​

4. Visão Estrutural​

5. Funcionamento na Prática​

Como os pontos de retenção se encadeiam​

Instant Restore (Snapshot Tier)​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 ARM Template​

7. Controle e Segurança​

Quem pode criar e modificar políticas​

Impacto de alterar uma política existente​

8. Tomada de Decisão​

Escolha entre Standard e Enhanced Policy para VMs​

Configuração de retenção por criticidade​

Instant Restore: quantos dias configurar​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Monitorando compliance de políticas​

Alterar política de um item protegido​

Limites importantes​

12. Integração e Automação​

Azure Policy para aplicar Backup Policies automaticamente​

Automação de criação de políticas com Terraform​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 Recovery Point Objective (RPO) e Recovery Time Objective (RTO)

3.2 Tipos de Backup

3.3 Estrutura de uma Backup Policy para VMs (Recovery Services Vault)

3.4 Standard Policy vs Enhanced Policy (VMs)

3.5 Políticas para outros workloads

4. Visão Estrutural

5. Funcionamento na Prática

Como os pontos de retenção se encadeiam

Instant Restore (Snapshot Tier)

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Azure PowerShell

6.4 ARM Template

7. Controle e Segurança

Quem pode criar e modificar políticas

Impacto de alterar uma política existente

8. Tomada de Decisão

Escolha entre Standard e Enhanced Policy para VMs

Configuração de retenção por criticidade

Instant Restore: quantos dias configurar

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Monitorando compliance de políticas

Alterar política de um item protegido

Limites importantes

12. Integração e Automação

Azure Policy para aplicar Backup Policies automaticamente

Automação de criação de políticas com Terraform

13. Resumo Final