Fundamentação Teórica: Create a Recovery Services Vault

1. Intuição Inicial

Imagine que você tem um servidor crítico rodando sua aplicação. Um dia, por erro humano, um disco falha ou alguém exclui acidentalmente arquivos importantes. Sem um plano de proteção, você perdeu dados. Com um plano, você restaura tudo em minutos.

O Recovery Services Vault é exatamente esse "cofre de proteção" no Azure. Ele é um contêiner gerenciado que armazena dados de backup e de recuperação de desastres para recursos Azure e on-premises.

A analogia mais direta: pense em um cofre bancário. Você deposita lá seus bens mais valiosos (backups de VMs, bancos de dados, arquivos) e, quando precisar, retira com garantia de integridade. O banco (Azure) gerencia a infraestrutura do cofre; você gerencia o que entra e as regras de acesso.

Na prática, o Recovery Services Vault serve para dois grandes propósitos:

Azure Backup: proteger dados contra exclusão, corrupção ou falha
Azure Site Recovery (ASR): replicar máquinas virtuais para outra região e garantir continuidade de negócio em caso de desastre regional

2. Contexto

Dentro do ecossistema Azure, proteção de dados está organizada em camadas. O Recovery Services Vault é o elemento central dessa estrutura.

100%

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

O vault existe porque o Azure precisava de um recurso unificado que:

Gerenciasse metadados e dados de backup com redundância automática
Centralizasse políticas de retenção e agendamento
Fornecesse controle de acesso granular via RBAC
Garantisse conformidade com soft delete e imutabilidade
Permitisse monitoramento e alertas centralizados

Sem o vault, cada solução de backup seria isolada, sem visibilidade unificada e sem as garantias de segurança integradas.

3. Construção dos Conceitos

3.1 O que compõe um Recovery Services Vault

Antes de criar o vault, você precisa entender seus elementos fundamentais.

Região (Region): o vault é um recurso regional. Ele só pode proteger recursos na mesma região ou replicar recursos para outra região. Você não pode fazer backup de uma VM no Brasil South em um vault no East US.

Redundância de armazenamento: define como os dados de backup são replicados fisicamente. Isso é configurado no vault e afeta custo e resiliência.

Tipo	Sigla	Cópias	Cenário de uso
Locally Redundant Storage	LRS	3 cópias na mesma zona/datacenter	Custo baixo, aceitável se houver ASR
Geo-Redundant Storage	GRS	6 cópias em 2 regiões distintas	Proteção contra desastre regional
Zone-Redundant Storage	ZRS	3 cópias em zonas diferentes	Alta disponibilidade zonal

O padrão é GRS. Se o vault for usado apenas com ASR e os dados de replicação já estiverem em outra região, LRS pode ser suficiente, reduzindo custo.

Cross Region Restore (CRR): funcionalidade que permite restaurar backups de uma região secundária, mesmo que a região primária esteja indisponível. Só disponível quando a redundância é GRS.

Soft Delete: proteção adicional que retém dados de backup por 14 dias após exclusão, evitando perda acidental ou maliciosa. Habilitado por padrão desde 2020.

Imutabilidade: impede alteração ou exclusão de dados de backup durante o período de retenção definido. Crítico para conformidade regulatória.

3.2 Backup Policies

Uma Backup Policy é um conjunto de regras que define:

Com que frequência fazer backup (frequência de agendamento)
Em que horário executar
Por quanto tempo reter os pontos de recuperação

As políticas são associadas ao vault e aplicadas a itens protegidos individuais.

100%

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

Existem dois tipos de política:

Standard Policy: backup diário com opções de retenção granular por dia, semana, mês e ano
Enhanced Policy: suporta backup por hora (hourly backup), oferecendo RPO (Recovery Point Objective) menor, mas com custo superior

4. Visão Estrutural

O Recovery Services Vault se posiciona como hub central entre fontes de dados e destinos de proteção.

100%

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

5. Funcionamento na Prática

Ciclo de vida de um Recovery Services Vault

100%

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

Um comportamento crítico e frequentemente ignorado: a redundância de armazenamento só pode ser alterada antes do primeiro backup ser executado. Após isso, a única forma de mudar é excluir todos os itens protegidos, alterar a configuração e re-proteger tudo.

Pré-requisitos para criação

Antes de criar o vault, você precisa ter:

Uma subscription ativa no Azure
Um Resource Group existente ou permissão para criar um
Permissão RBAC: mínimo de Contributor no Resource Group ou Backup Contributor no escopo desejado
Definir a região com base nos recursos que serão protegidos

6. Formas de Implementação

6.1 Portal Azure (Interface Gráfica)

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

Passos:

Acesse portal.azure.com
Pesquise "Recovery Services vaults" na barra de busca
Clique em "Create"
Preencha os campos:
- Subscription: selecione a subscription correta
- Resource Group: crie um novo ou selecione existente
- Vault name: nome único no Resource Group (3 a 50 caracteres, alfanumérico e hifens)
- Region: mesma região dos recursos a proteger
Clique em "Review + Create" e depois "Create"

Após a criação, acesse o vault e configure imediatamente em Properties > Backup Configuration:

Storage Replication Type (LRS, GRS ou ZRS)
Cross Region Restore (requer GRS)
Security Settings (Soft Delete, imutabilidade)

Limitação: processo manual, não replicável, sujeito a erro humano em escala.

6.2 Azure CLI

Quando usar: scripts de automação, pipelines CI/CD, criação em lote.

# Criar Resource Group (se necessário)
az group create \
  --name rg-backup-prod \
  --location brazilsouth

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

# Configurar redundância de armazenamento
az backup vault backup-properties set \
  --resource-group rg-backup-prod \
  --name rsv-prod-brazilsouth \
  --backup-storage-redundancy GeoRedundant

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

Vantagem: rápido, scriptável, integrável a pipelines. Limitação: requer Azure CLI instalado e autenticado.

6.3 Azure PowerShell

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

# Criar Resource Group
New-AzResourceGroup -Name "rg-backup-prod" -Location "brazilsouth"

# Criar Recovery Services Vault
New-AzRecoveryServicesVault `
  -ResourceGroupName "rg-backup-prod" `
  -Name "rsv-prod-brazilsouth" `
  -Location "brazilsouth"

# Obter referência ao vault
$vault = Get-AzRecoveryServicesVault `
  -ResourceGroupName "rg-backup-prod" `
  -Name "rsv-prod-brazilsouth"

# Configurar redundância
Set-AzRecoveryServicesBackupProperty `
  -Vault $vault `
  -BackupStorageRedundancy GeoRedundant

6.4 ARM Template (Azure Resource Manager)

Quando usar: Infrastructure as Code, ambientes com governança rígida, implantações repetíveis e versionadas.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.RecoveryServices/vaults",
      "apiVersion": "2023-01-01",
      "name": "rsv-prod-brazilsouth",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "RS0",
        "tier": "Standard"
      },
      "properties": {}
    }
  ]
}

Vantagem: versionável, auditável, reutilizável em múltiplos ambientes. Limitação: curva de aprendizado maior; configurações pós-criação (redundância, soft delete) exigem recursos adicionais no template.

6.5 Terraform

Quando usar: ambientes multi-cloud, times que já usam Terraform como padrão IaC.

resource "azurerm_resource_group" "backup" {
  name     = "rg-backup-prod"
  location = "Brazil South"
}

resource "azurerm_recovery_services_vault" "main" {
  name                = "rsv-prod-brazilsouth"
  location            = azurerm_resource_group.backup.location
  resource_group_name = azurerm_resource_group.backup.name
  sku                 = "Standard"

  soft_delete_enabled = true

  storage_mode_type = "GeoRedundant"
}

Vantagem: state management, plano de execução, integração nativa com outros recursos Azure. Limitação: exige Terraform instalado e provider AzureRM configurado.

7. Controle e Segurança

RBAC no Recovery Services Vault

O vault suporta roles específicas para separar responsabilidades:

Role	Capacidade
Backup Contributor	Criar/gerenciar backups, criar vaults, não pode deletar
Backup Operator	Habilitar backup, disparar jobs, restaurar. Não pode remover proteção
Backup Reader	Somente leitura. Visualizar backups e jobs
Site Recovery Contributor	Gerenciar ASR completamente, exceto criar vaults
Site Recovery Operator	Executar failover e failback

Soft Delete

Quando habilitado (padrão), ao excluir um item protegido:

Os dados são retidos por 14 dias adicionais no estado "soft deleted"
Durante esse período, a exclusão pode ser desfeita (undelete)
Após 14 dias, os dados são permanentemente removidos
É possível estender para 180 dias com configuração de retenção estendida

Atenção: mesmo com o vault "vazio" de itens ativos, se houver itens em soft delete, o vault não pode ser excluído. Você precisa fazer purge (exclusão permanente) dos itens soft deleted antes.

Imutabilidade

Três estados possíveis:

Estado	Comportamento
Disabled	Sem proteção de imutabilidade
Enabled (unlocked)	Dados imutáveis, mas pode ser desabilitado
Enabled (locked)	Dados imutáveis, não pode ser revertido. Irreversível

O estado "locked" é exigido por regulamentações como LGPD, SOC 2 e regulações bancárias brasileiras quando se exige prova de que backups não foram adulterados.

8. Tomada de Decisão

Redundância de armazenamento

Situação	Melhor escolha	Motivo
VM crítica sem ASR configurado	GRS	Proteção contra desastre regional via backup
VM com ASR replicando para outra região	LRS	ASR já garante recuperação regional; LRS reduz custo
Requisito de disponibilidade zonal	ZRS	Protege contra falha de zona dentro da mesma região
Ambiente de dev/test	LRS	Custo mínimo; perda tolerável

Número de vaults por ambiente

Cenário	Recomendação	Motivo
Ambientes prod, staging, dev separados	Um vault por ambiente	Isolamento de políticas e acesso
Múltiplas regiões	Um vault por região	Vault é regional; dados devem ficar próximos dos recursos
Conformidade com múltiplos departamentos	Um vault por departamento ou BU	Isolamento de RBAC e políticas de retenção
Organização pequena, recursos simples	Um único vault	Simplicidade operacional

9. Boas Práticas

Nomenclatura padronizada: use uma convenção clara e consistente. Exemplo: rsv-[ambiente]-[regiao] como rsv-prod-brazilsouth ou rsv-dev-eastus2.

Tags obrigatórias: aplique tags como Environment, CostCenter, Owner e Application no vault para facilitar governança e chargeback.

Política de acesso mínimo: use as roles específicas de backup (Backup Operator, Backup Contributor) em vez de dar Contributor ou Owner para operadores de backup.

Soft Delete sempre habilitado: nunca desabilite em ambientes de produção. O custo de 14 dias de retenção adicional é desprezível frente ao risco de perda irreversível.

Separação por região: nunca tente centralizar backups de múltiplas regiões em um único vault. Isso não é suportado e compromete a latência e a conformidade de residência de dados.

Monitoramento proativo: configure alertas no Azure Monitor para falhas de backup job. Um backup silenciosamente falhando por semanas é um risco grave.

Testar restore regularmente: criar backups sem nunca testar a restauração é uma prática de falsa segurança. Agende testes periódicos de restore em ambientes isolados.

10. Erros Comuns

Erro: criar o vault em região diferente dos recursos Por que acontece: o operador cria o vault em uma região "padrão" sem verificar onde estão as VMs. Como evitar: verifique a região dos recursos protegidos antes de criar o vault. A regra é: vault e recurso na mesma região para backup.

Erro: esquecer de configurar a redundância antes do primeiro backup Por que acontece: o vault é criado e a proteção é ativada imediatamente sem revisar configurações de storage. Como evitar: crie o vault, configure imediatamente storage redundancy e soft delete, só então ative a proteção de itens.

Erro: tentar excluir um vault com itens protegidos ou em soft delete Por que acontece: o operador remove VMs do Azure e assume que o vault está vazio. Como evitar: antes de excluir o vault, verifique em Backup Items, Replication Items e Backup Infrastructure se há itens ativos. Execute purge nos itens soft deleted.

Erro: usar um único vault para todos os ambientes Por que acontece: simplificação excessiva para reduzir gestão. Como evitar: separe vaults por ambiente (prod, staging, dev) para evitar que políticas de retenção de dev impactem prod e para facilitar RBAC.

Erro: não configurar alertas de falha de backup Por que acontece: assume-se que "se não tem alerta, está funcionando". Como evitar: configure imediatamente após a criação do vault as notificações de backup via Azure Monitor ou email alerts no vault.

11. Operação e Manutenção

Monitoramento diário

No portal, acesse o vault e verifique:

Backup Jobs: jobs com status Failed ou Warning exigem atenção imediata
Backup Alerts: alertas ativos que precisam ser investigados
Backup Reports (via Azure Monitor Workbooks): visão histórica de compliance de backup

Limites importantes do Recovery Services Vault

Limite	Valor
Vaults por subscription	Sem limite documentado, mas recomendado organizar por Resource Group
VMs protegidas por vault	1000 VMs por vault (recomendação de performance)
Política de backup por vault	Até 200 políticas
Pontos de recuperação por item	Varia por tipo, até 9999 para VMs
Tamanho máximo de disco protegido (VM)	32 TB

Gerenciamento de custos

Os custos do Recovery Services Vault são compostos por:

Instância protegida: cobrado por VM protegida, baseado no tamanho do disco
Armazenamento de backup: cobrado pelo volume de dados armazenados, com custo diferente para LRS, ZRS e GRS
Transações: operações de leitura/escrita no armazenamento

Monitore via Azure Cost Management filtrando pelo Resource Group ou tags do vault para visibilidade de custo por ambiente.

12. Integração e Automação

Integração com Azure Policy

Você pode usar Azure Policy para garantir que todas as VMs em uma subscription ou Resource Group estejam protegidas por um vault específico. A política integrada Configure backup on VMs of a location to an existing central Vault in the same location automatiza a associação de novas VMs ao vault.

100%

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

Automação com Azure Automation / Logic Apps

Padrões comuns de automação:

Trigger backup on-demand via runbook quando uma mudança significativa é detectada (ex: antes de um deploy)
Relatório semanal de compliance enviado por email via Logic App consultando a API do vault
Auto-register novas VMs ao vault via event-driven automation com Azure Event Grid

API REST

O vault expõe APIs REST completas. Exemplo de criação via API:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.RecoveryServices/vaults/{vaultName}?api-version=2023-01-01

Com body:

{
  "location": "brazilsouth",
  "sku": {
    "name": "RS0",
    "tier": "Standard"
  },
  "properties": {}
}

13. Resumo Final

O que é: contêiner regional no Azure que armazena dados de backup e configurações de recuperação de desastres (ASR) para recursos Azure e on-premises.

Pontos essenciais:

O vault é sempre regional: deve estar na mesma região dos recursos protegidos
A redundância de armazenamento (LRS, GRS, ZRS) só pode ser alterada antes do primeiro backup
Soft Delete está habilitado por padrão e retém dados por 14 dias após exclusão. Vaults com itens soft deleted não podem ser excluídos sem purge
Cross Region Restore só está disponível com redundância GRS
Um vault não pode ser excluído enquanto houver itens protegidos, replicados ou em soft delete
Use roles específicas de backup (Backup Contributor, Backup Operator) em vez de roles genéricas para seguir o princípio de menor privilégio

Diferenças críticas:

Ponto	Detalhe
GRS vs LRS	GRS para backup primário; LRS quando ASR já provê resiliência regional
Soft Delete vs Imutabilidade	Soft delete protege contra exclusão acidental; imutabilidade protege contra adulteração
Locked vs Unlocked Immutability	Locked é irreversível. Use apenas quando exigido por regulação
Standard vs Enhanced Policy	Enhanced suporta backup por hora (menor RPO), com custo maior

O que precisa ser lembrado para o AZ-104:

Vault criado antes de qualquer configuração de backup
Redundância configurada imediatamente após criação, antes do primeiro backup
Vault e recurso protegido devem estar na mesma região
Soft delete impede exclusão imediata de dados; requer purge manual para exclusão permanente
RBAC granular disponível com roles específicas de backup e site recovery

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 O que compõe um Recovery Services Vault​

3.2 Backup Policies​

4. Visão Estrutural​

5. Funcionamento na Prática​

Ciclo de vida de um Recovery Services Vault​

Pré-requisitos para criação​

6. Formas de Implementação​

6.1 Portal Azure (Interface Gráfica)​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 ARM Template (Azure Resource Manager)​

6.5 Terraform​

7. Controle e Segurança​

RBAC no Recovery Services Vault​

Soft Delete​

Imutabilidade​

8. Tomada de Decisão​

Redundância de armazenamento​

Número de vaults por ambiente​

9. Boas Práticas​

10. Erros Comuns​

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

Monitoramento diário​

Limites importantes do Recovery Services Vault​

Gerenciamento de custos​

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

Integração com Azure Policy​

Automação com Azure Automation / Logic Apps​

API REST​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 O que compõe um Recovery Services Vault

3.2 Backup Policies

4. Visão Estrutural

5. Funcionamento na Prática

Ciclo de vida de um Recovery Services Vault

Pré-requisitos para criação

6. Formas de Implementação

6.1 Portal Azure (Interface Gráfica)

6.2 Azure CLI

6.3 Azure PowerShell

6.4 ARM Template (Azure Resource Manager)

6.5 Terraform

7. Controle e Segurança

RBAC no Recovery Services Vault

Soft Delete

Imutabilidade

8. Tomada de Decisão

Redundância de armazenamento

Número de vaults por ambiente

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Monitoramento diário

Limites importantes do Recovery Services Vault

Gerenciamento de custos

12. Integração e Automação

Integração com Azure Policy

Automação com Azure Automation / Logic Apps

API REST

13. Resumo Final