Fundamentação Teórica: Manage Virtual Machine Disks

1. Intuição Inicial

Pense em uma VM como um computador completo. Todo computador tem pelo menos um disco onde o sistema operacional está instalado. Mas computadores de trabalho sério também têm discos adicionais para dados, logs, backups e bancos de dados, cada um com características diferentes de velocidade e tamanho.

No Azure, os discos de uma VM funcionam da mesma forma, mas com uma diferença fundamental em relação ao hardware físico: eles são objetos independentes da VM. Um disco gerenciado no Azure existe como um recurso separado que pode ser criado, ampliado, desconectado, movido e protegido independentemente da VM à qual está conectado.

Gerenciar discos de VM significa entender esses objetos: seus tipos (HDD, SSD, Ultra), suas características de performance, como adicioná-los e removê-los de VMs em operação, como expandir sua capacidade, como tirar snapshots para backup e como proteger contra perda de dados.

2. Contexto

Tipos de armazenamento associados a VMs

100%

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

Managed Disks são o tipo moderno e recomendado: discos gerenciados pelo Azure como recursos ARM independentes, com criptografia automática, replicação e snapshots.

Unmanaged Disks (o tipo legado) eram VHDs armazenados em Storage Accounts gerenciadas pelo cliente. Este formato é considerado legado e não deve ser usado em novos ambientes.

Temporary Disk é coberto no módulo de VM Sizes e não é um Managed Disk.

Por que discos são objetos independentes da VM

No mundo físico, um HD está dentro do computador. Se o computador queima, o HD vai junto (a menos que você o remova antes).

No Azure, discos gerenciados são objetos separados da VM. Isso permite:

Aumentar o disco de SO sem recriar a VM
Mover um disco de dados de uma VM para outra
Criar snapshots do disco sem parar a VM (para maioria dos tipos)
Proteger dados em disco mesmo após deletar a VM (se não for deletado junto)

3. Construção dos Conceitos

3.1 Tipos de disco por performance

O Azure oferece quatro tipos de disco Managed, cada um com características diferentes de performance e custo:

Tipo	Sigla	Tecnologia	IOPS máx	Throughput máx	Latência	Caso de uso
Ultra Disk	Ultra	NVMe	160.000	2.000 MB/s	< 1ms	Bancos de dados tier-1, SAP HANA
Premium SSD v2	Prem v2	SSD NVMe	80.000	1.200 MB/s	< 1ms	Bancos de dados tier-2, workloads I/O intensivos
Premium SSD	P	SSD	20.000	900 MB/s	~1ms	Produção geral, bancos de dados
Standard SSD	E	SSD	6.000	750 MB/s	~5ms	Web servers, dev/test leve
Standard HDD	S	HDD	2.000	500 MB/s	~10ms	Backups, arquivos frios

3.2 Nomenclatura dos discos Premium SSD

Os discos Premium SSD seguem uma nomenclatura por tamanho (P-tiers):

Tier	Tamanho	IOPS	Throughput
P4	32 GB	120	25 MB/s
P6	64 GB	240	50 MB/s
P10	128 GB	500	100 MB/s
P15	256 GB	1.100	125 MB/s
P20	512 GB	2.300	150 MB/s
P30	1 TB	5.000	200 MB/s
P40	2 TB	7.500	250 MB/s
P50	4 TB	7.500	250 MB/s
P60	8 TB	16.000	500 MB/s
P70	16 TB	18.000	750 MB/s
P80	32 TB	20.000	900 MB/s

O tamanho do disco determina sua performance. Um disco P30 de 1 TB tem mais IOPS que um P10 de 128 GB. Se você precisa de mais IOPS mas não precisa de mais espaço, pode fazer performance tier bursting ou usar um tier mais alto.

3.3 Caching de disco

O caching de disco é uma configuração aplicada por disco que define se o host físico usa sua cache de alta velocidade (RAM/NVMe local) para operações naquele disco:

Modo de Cache	Comportamento	Indicado para
None	Sem cache; leitura e escrita vão direto ao Azure Storage	Discos de log de banco de dados, discos Ultra
ReadOnly	Leituras servidas do cache; escritas vão direto	Disco de SO, discos com mais leituras que escritas
ReadWrite	Leituras e escritas passam pelo cache	Apenas quando a aplicação garante consistência (journaled FS)

Atenção crítica: ReadWrite caching pode causar perda de dados em caso de falha do host se a aplicação não tiver mecanismos de consistência. Para discos de dados de banco de dados, use None ou ReadOnly.

3.4 Shared Disks (discos compartilhados)

Discos Premium SSD e Ultra Disk podem ser configurados como Shared Disks, permitindo que múltiplas VMs se conectem ao mesmo disco simultaneamente. Isso é usado para implementar clusters de alta disponibilidade como Windows Server Failover Clustering (WSFC) ou Linux Pacemaker.

100%

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

3.5 Snapshots

Um Snapshot é uma cópia ponto-no-tempo de um disco gerenciado. Snapshots são somente leitura e podem ser usados para:

Criar backups antes de operações de risco
Criar discos novos baseados no estado capturado
Restaurar um disco para um estado anterior
Copiar discos entre regiões ou subscriptions

Tipos de snapshot:

Full snapshot: cópia completa do disco. Custo baseado no tamanho usado, não no tamanho provisionado.
Incremental snapshot: captura apenas os blocos que mudaram desde o último snapshot. Muito mais econômico para uso recorrente.

100%

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

3.6 Disk Bursting

Discos Premium SSD (P1 a P20) e Standard SSD suportam bursting: capacidade de exceder temporariamente os limites de IOPS e throughput do tier durante picos de carga.

On-demand bursting (Premium SSD P30 e acima com bursting habilitado): permite exceder o limite por períodos prolongados, com créditos que se acumulam quando o disco está abaixo do limite.

Credit-based bursting (P1 a P20): créditos acumulam quando o disco está abaixo do limite e são consumidos quando ultrapassa, similar ao modelo de VMs B-series.

4. Visão Estrutural

Estrutura completa de discos em uma VM

100%

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

Ciclo de vida de um disco de dados

100%

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

5. Funcionamento na Prática

Expandir um disco (operação crítica e não reversível)

Expandir um disco é uma operação unidirecional: discos não podem ser reduzidos de tamanho. Uma vez expandido de 128 GB para 256 GB, não há como voltar para 128 GB sem recriar o disco.

O processo de expansão tem dois componentes:

1. Expandir o disco no Azure (plano de gerenciamento):

az disk update --resource-group rg-prod --name vm-data-disk --size-gb 512

2. Estender a partição dentro do sistema operacional: Só expandir o disco no Azure não é suficiente. O sistema operacional ainda vê o tamanho antigo até que você estenda a partição e o sistema de arquivos dentro da VM.

No Windows:

# Dentro da VM - Disk Management GUI ou via PowerShell:
$partition = Get-Partition -DriveLetter D
Resize-Partition -DiskNumber $partition.DiskNumber -PartitionNumber $partition.PartitionNumber -Size (Get-PartitionSupportedSize -DiskNumber $partition.DiskNumber -PartitionNumber $partition.PartitionNumber).SizeMax

No Linux:

# Dentro da VM:
sudo growpart /dev/sdc 1  # estender partição
sudo resize2fs /dev/sdc1  # estender filesystem ext4
# ou para XFS:
sudo xfs_growfs /mountpoint

Adicionar disco de dados sem parar a VM

Discos de dados podem ser adicionados (attach) e removidos (detach) de VMs em execução sem necessidade de parar ou reiniciar, com exceção de alguns SKUs de VM mais antigos.

O processo correto para detach em produção (Linux):

# 1. Dentro da VM: desmontar o disco antes de fazer detach
sudo umount /dev/sdc1

# 2. No Azure: fazer o detach
az vm disk detach --resource-group rg-prod --vm-name vm-01 --name data-disk-01

# Fazer detach sem desmontar pode causar corrupção de dados

Comportamentos não óbvios

Expandir disco de SO requer desalocação na maioria dos casos. Diferente de discos de dados que podem ser expandidos online (com VM em execução), o disco de SO geralmente requer que a VM esteja deallocated antes da expansão. Verifique a documentação do SKU e OS antes de planejar a operação.

O número de discos de dados suportados depende do SKU da VM. Uma VM Standard_B2s suporta 4 discos de dados no máximo. Uma Standard_D16s_v5 suporta 32 discos. Tentativa de adicionar mais discos que o suportado pelo SKU falhará. Verifique com az vm list-vm-resize-options ou a documentação do SKU.

Discos têm uma opção deleteOption que determina o que acontece quando a VM é deletada. Por padrão, discos de dados têm deleteOption = Detach (ficam orphan quando a VM é deletada), enquanto discos de SO criados pelo portal têm deleteOption = Delete (são deletados com a VM). Isso pode causar discos órfãos e custos não esperados.

Snapshots incrementais não podem ser copiados para outra região diretamente. Para copiar dados entre regiões, você precisa criar um disco a partir do snapshot incremental na região de origem e então copiar o disco para a região destino, ou usar Azure Backup que gerencia isso automaticamente.

Discos Premium SSD sem o sufixo s no VM SKU não têm o benefício de caching. Se a VM não suporta Premium Storage (SKU sem s), o disco Premium SSD funciona mas sem os benefícios de caching do host, perdendo parte da vantagem de performance.

6. Formas de Implementação

Portal do Azure

Quando usar: operações pontuais, visualização do estado dos discos

Para adicionar disco de dados:

Portal > VM > Disks > + Add data disk
Selecionar disco existente ou criar novo
Configurar LUN, caching
Save

Para expandir disco:

Portal > VM > Disks > clicar no disco
Size + performance
Mudar o tamanho e o tier se necessário
Save
Depois: estender partição dentro do OS

Para criar snapshot:

Portal > navegar até o disco
+ Create snapshot
Nomear, escolher tipo (Full ou Incremental)
Review + Create

Azure CLI

# Ver discos de uma VM
az vm show \
  --resource-group "rg-producao" \
  --name "vm-db-01" \
  --query "{OS: storageProfile.osDisk, Data: storageProfile.dataDisks}" \
  --output json

# Criar disco de dados Premium SSD (P30 = 1TB)
az disk create \
  --resource-group "rg-producao" \
  --name "vm-db-01-data-01" \
  --size-gb 1024 \
  --sku "Premium_LRS" \
  --location "brazilsouth" \
  --zone 1  # Se VM está em Availability Zone 1

# Adicionar disco existente a uma VM (sem parar)
az vm disk attach \
  --resource-group "rg-producao" \
  --vm-name "vm-db-01" \
  --name "vm-db-01-data-01" \
  --caching None \
  --lun 0

# Criar e adicionar novo disco em uma operação
az vm disk attach \
  --resource-group "rg-producao" \
  --vm-name "vm-db-01" \
  --name "vm-db-01-data-02" \
  --new \
  --size-gb 512 \
  --sku "Premium_LRS" \
  --caching ReadOnly \
  --lun 1

# Expandir disco de dados (pode ser feito com VM em execução)
az disk update \
  --resource-group "rg-producao" \
  --name "vm-db-01-data-01" \
  --size-gb 2048

# Expandir disco de SO (geralmente requer desalocação)
az vm deallocate \
  --resource-group "rg-producao" \
  --name "vm-web-01"

az disk update \
  --resource-group "rg-producao" \
  --name "vm-web-01-osdisk" \
  --size-gb 256

az vm start \
  --resource-group "rg-producao" \
  --name "vm-web-01"

# Remover disco de dados (detach - requer desmontar no OS antes)
az vm disk detach \
  --resource-group "rg-producao" \
  --vm-name "vm-db-01" \
  --name "vm-db-01-data-01"

# Criar snapshot incremental (recomendado para uso recorrente)
DISK_ID=$(az disk show \
  --resource-group "rg-producao" \
  --name "vm-db-01-data-01" \
  --query "id" --output tsv)

az snapshot create \
  --resource-group "rg-backups" \
  --name "snap-vm-db-01-data-01-$(date +%Y%m%d)" \
  --source "$DISK_ID" \
  --incremental \
  --location "brazilsouth"

# Criar snapshot full
az snapshot create \
  --resource-group "rg-backups" \
  --name "snap-vm-db-01-data-01-full-$(date +%Y%m%d)" \
  --source "$DISK_ID" \
  --location "brazilsouth"

# Criar novo disco a partir de snapshot
SNAP_ID=$(az snapshot show \
  --resource-group "rg-backups" \
  --name "snap-vm-db-01-data-01-20260324" \
  --query "id" --output tsv)

az disk create \
  --resource-group "rg-producao" \
  --name "vm-db-01-data-01-restored" \
  --source "$SNAP_ID" \
  --sku "Premium_LRS" \
  --location "brazilsouth"

# Listar discos órfãos (sem VM associada) - para limpeza
az disk list \
  --query "[?managedBy == null].{Name: name, RG: resourceGroup, Size: diskSizeGb, SKU: sku.name}" \
  --output table

# Mudar o tipo de disco (ex: Standard SSD para Premium SSD)
# Requer que disco esteja desconectado OU com VM desalocada
az disk update \
  --resource-group "rg-producao" \
  --name "vm-web-01-data-01" \
  --sku "Premium_LRS"

# Configurar deleteOption para evitar discos órfãos
# (ao criar a VM com Bicep/ARM, definir nos discos)
# Ou atualizar após criação:
az vm update \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --set storageProfile.dataDisks[0].deleteOption=Delete

# Habilitar on-demand bursting em disco Premium SSD P30+
az disk update \
  --resource-group "rg-producao" \
  --name "vm-db-01-data-01" \
  --enable-bursting true

Azure PowerShell

# Criar e adicionar disco de dados
$diskConfig = New-AzDiskConfig `
  -Location "brazilsouth" `
  -DiskSizeGB 1024 `
  -SkuName "Premium_LRS" `
  -CreateOption Empty `
  -Zone 1

$disk = New-AzDisk `
  -ResourceGroupName "rg-producao" `
  -DiskName "vm-db-01-data-01" `
  -Disk $diskConfig

$vm = Get-AzVM -ResourceGroupName "rg-producao" -Name "vm-db-01"
$vm = Add-AzVMDataDisk `
  -VM $vm `
  -Name "vm-db-01-data-01" `
  -ManagedDiskId $disk.Id `
  -Lun 0 `
  -Caching "None" `
  -CreateOption Attach

Update-AzVM -ResourceGroupName "rg-producao" -VM $vm

# Expandir disco de dados
$disk = Get-AzDisk -ResourceGroupName "rg-producao" -DiskName "vm-db-01-data-01"
$disk.DiskSizeGB = 2048
Update-AzDisk -ResourceGroupName "rg-producao" -DiskName $disk.Name -Disk $disk

# Criar snapshot incremental
$snapshotConfig = New-AzSnapshotConfig `
  -Location "brazilsouth" `
  -CreateOption Copy `
  -Incremental `
  -SourceResourceId (Get-AzDisk -ResourceGroupName "rg-producao" -DiskName "vm-db-01-data-01").Id

New-AzSnapshot `
  -ResourceGroupName "rg-backups" `
  -SnapshotName "snap-vm-db-01-$(Get-Date -Format 'yyyyMMdd')" `
  -Snapshot $snapshotConfig

# Listar discos órfãos
Get-AzDisk |
  Where-Object { $null -eq $_.ManagedBy } |
  Select-Object Name, ResourceGroupName, DiskSizeGB, Sku |
  Format-Table

Bicep

// Criar discos de dados como recursos independentes
resource dataDisk01 'Microsoft.Compute/disks@2022-07-02' = {
  name: 'vm-db-01-data-01'
  location: 'brazilsouth'
  zones: ['1']
  sku: {
    name: 'Premium_LRS'
  }
  properties: {
    creationData: {
      createOption: 'Empty'
    }
    diskSizeGB: 1024
    diskIOPSReadWrite: 5000  // Ultra Disk: IOPS customizável
    diskMBpsReadWrite: 200   // Ultra Disk: throughput customizável
    burstingEnabled: true    // Premium SSD: habilitar bursting
  }
}

// VM com discos e deleteOption configurados
resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: 'vm-db-01'
  location: 'brazilsouth'
  zones: ['1']
  properties: {
    storageProfile: {
      osDisk: {
        name: 'vm-db-01-osdisk'
        createOption: 'FromImage'
        deleteOption: 'Delete'  // Disco OS deletado com a VM
        managedDisk: {
          storageAccountType: 'Premium_LRS'
        }
        caching: 'ReadWrite'
        diskSizeGB: 128
      }
      dataDisks: [
        {
          lun: 0
          name: dataDisk01.name
          createOption: 'Attach'
          deleteOption: 'Detach'  // Disco de dados NÃO deletado com a VM
          managedDisk: {
            id: dataDisk01.id
          }
          caching: 'None'  // Sem cache para disco de dados de DB
        }
      ]
    }
  }
}

7. Controle e Segurança

Criptografia de discos

Todos os discos gerenciados no Azure têm criptografia habilitada por padrão via SSE (Storage Service Encryption). Há três modelos:

Modelo	Chaves	Controle
PMK (Platform Managed Keys)	Microsoft gerencia	Automático, sem configuração
CMK (Customer Managed Keys)	Cliente gerencia no Key Vault	Requer Disk Encryption Set
Double Encryption	Duas camadas: PMK + CMK	Máxima segurança

Para CMK, o Disk Encryption Set é necessário (conforme coberto no módulo de Encryption at Host).

Backup de discos com Azure Backup

O Azure Backup é a solução recomendada para backup consistente de VMs completas (OS + todos os discos):

# Habilitar backup de uma VM
az backup protection enable-for-vm \
  --resource-group "rg-producao" \
  --vault-name "rsv-backup-prod" \
  --vm "vm-db-01" \
  --policy-name "DefaultPolicy"

# Trigger de backup imediato
az backup protection backup-now \
  --resource-group "rg-producao" \
  --vault-name "rsv-backup-prod" \
  --container-name "IaasVMContainer;iaasvmcontainerv2;rg-producao;vm-db-01" \
  --item-name "vm;iaasvmcontainerv2;rg-producao;vm-db-01" \
  --backup-management-type AzureIaasVM

8. Tomada de Decisão

Escolha do tipo de disco

Situação	Tipo recomendado	Motivo
Banco de dados tier-1 (SQL, Oracle)	Premium SSD ou Ultra Disk	Baixa latência, alto IOPS
Servidor SAP HANA	Ultra Disk	Latência < 1ms, IOPS altíssimo
Disco de SO para web server	Premium SSD (P10 a P20)	Performance adequada, custo razoável
Servidor de arquivos com acesso frequente	Standard SSD (E)	Custo menor, performance aceitável
Backup e arquivamento	Standard HDD (S)	Custo mínimo para dados frios
Cache de leitura para CDN/web	Premium SSD com ReadOnly cache	Maximiza leituras do cache
Logs de banco de dados	Premium SSD com caching None	Escritas sequenciais não beneficiam de cache
Dev/test com baixo uso	Standard SSD (E)	Custo controlado

Full snapshot vs. Incremental snapshot

Situação	Tipo	Motivo
Primeiro snapshot de um disco	Full ou Incremental	Para incrementais, o primeiro sempre tem custo total
Backup diário recorrente	Incremental	Paga apenas pelas mudanças, muito mais econômico
Copiar disco para outra região	Full	Incrementais têm restrições de cópia entre regiões
Restauração de ponto específico no tempo	Incremental (se cadeia intacta)	Mais econômico para séries históricas

Cache de disco

Workload	Disco OS	Discos de dados (leitura)	Discos de dados (escrita/log)
SQL Server	ReadOnly ou ReadWrite	ReadOnly	None
IIS/Apache web server	ReadOnly	ReadOnly	None
VM de desenvolvimento	ReadWrite	ReadOnly	None
Redis, Memcached	ReadOnly	None	None
Aplicação genérica	ReadOnly	ReadOnly	None

9. Boas Práticas

Sempre configure deleteOption nos discos ao criar VMs via IaC. O padrão de Detach para discos de dados significa que eles ficam como recursos órfãos quando a VM é deletada, gerando custo contínuo sem uso. Decida conscientemente: Delete para discos temporários/descartáveis, Detach para discos com dados que devem sobreviver à VM.

Use snapshots incrementais para backups regulares. A economia em relação a snapshots full pode ser de 80-95% em discos com baixa taxa de mudança. Configure uma política de snapshots incrementais diários com retenção de 30 dias para um custo de backup muito menor que snapshots full.

Separe dados por função em discos diferentes. Não coloque logs de banco de dados no mesmo disco que os arquivos de dados. Discos separados permitem configurações de cache diferentes (None para logs, ReadOnly para dados) e permitem backup independente de cada componente.

Monitore IOPS e throughput antes de escolher o tipo de disco. Muitas equipes superprovisionam o tipo de disco por precaução. Uma semana de métricas do Azure Monitor mostrando o IOPS real costuma revelar que um disco P30 Premium SSD seria adequado onde foi colocado um Ultra Disk.

Não armazene nada crítico no disco temporário. O disco temporário (D: no Windows) é recriado a cada desalocação ou redimensionamento. Ele é adequado apenas para dados temporários de processamento, arquivos de swap/paginação e dados que podem ser regenerados.

Para bancos de dados, use Availability Zones com discos ZRS. Managed Disks com replicação ZRS (Zone Redundant Storage) replicam os dados entre 3 zonas de disponibilidade dentro de uma região, garantindo que a perda de uma zona não perca os dados.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Disco não usável após expansão no Azure	Expande no Azure mas esquece de estender partição no OS	Sempre executar growpart/resize2fs após expandir no Azure
Corrupção de dados ao fazer detach sem desmontar	Sistema de arquivo com writes pendentes no buffer	Sempre umount antes de detach no Linux; ejetar no Windows
Discos órfãos acumulando custo	deleteOption=Detach padrão, VM deletada sem deletar discos	Auditar discos sem VM associada regularmente; usar deleteOption=Delete
Tentar reduzir tamanho de disco	Operação não suportada	Discos só crescem; criar novo disco menor e migrar dados
Disco de dados ultrapassando limite de IOPS	Workload maior que o dimensionado	Monitorar IOPS e upgrade de tier antes de atingir o limite
Snapshot incremental com cadeia corrompida	Deletar snapshot do meio da cadeia	Nunca deletar snapshots do meio; sempre deletar do mais antigo
Ultra Disk em SKU de VM incompatível	Nem todos os SKUs suportam Ultra Disk	Verificar suporte antes: `az vm list-skus --query "capabilities[?name=='UltraSSDAvailable']"`
ReadWrite caching em disco de banco de dados	Equivoco de configuração causa perda de dados em falha	Usar None para logs de banco de dados; ReadOnly para dados

O erro mais crítico

Fazer az vm disk detach em um disco de banco de dados em produção sem primeiro parar o banco de dados e desmontar o disco dentro do OS. O sistema operacional Linux tentará continuar escrevendo para um dispositivo que não existe mais, resultando em corrupção de dados e falha da aplicação. O procedimento correto é sempre: parar a aplicação, desmontar o disco no OS, fazer o detach no Azure.

11. Operação e Manutenção

Inventário e auditoria de discos

# Listar todos os discos com informações detalhadas
az disk list \
  --query "[].{
    Nome: name,
    RG: resourceGroup,
    Tamanho: diskSizeGb,
    SKU: sku.name,
    VM: managedBy,
    Estado: diskState
  }" \
  --output table

# Discos órfãos (sem VM, com custo desnecessário)
az disk list \
  --query "[?managedBy == null && diskState != 'Unattached'].{Nome: name, RG: resourceGroup, Tamanho: diskSizeGb}" \
  --output table

# Custo estimado de discos órfãos via Resource Graph
az graph query -q "
Resources
| where type == 'microsoft.compute/disks'
| where isnull(properties.managedBy)
| project name, resourceGroup, diskSizeGb=properties.diskSizeGB, sku=sku.name, location
| order by diskSizeGb desc"

# Snapshots mais antigos que 30 dias
az snapshot list \
  --query "[?timeCreated < '$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)'].{Nome: name, Criado: timeCreated, Tamanho: diskSizeGb}" \
  --output table

Monitorar performance de discos

# IOPS consumido vs. limite do disco
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-db-01" \
  --metric "Data Disk IOPS Consumed Percentage" \
  --interval PT5M \
  --aggregation Average \
  --output table

# Throughput de disco
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-db-01" \
  --metric "Data Disk Bandwidth Consumed Percentage" \
  --interval PT5M \
  --aggregation Maximum \
  --output table

Limites importantes

Limite	Valor
Discos de dados por VM (máx)	64 (depende do SKU)
Tamanho máximo de disco gerenciado	32 TB
Snapshots por disco	Sem limite documentado (prático: alguns centenas)
Discos em Shared Disk (Premium SSD)	Até 5 VMs compartilhando
Discos em Shared Disk (Ultra Disk)	Até 5 VMs compartilhando
LUNs disponíveis por VM	0 a 63

12. Integração e Automação

Política de snapshots automatizados

O Azure Backup gerencia ciclos de vida completos, mas para cenários de snapshot puro é possível usar Azure Automation:

# Runbook: criar snapshots incrementais diários e limpar os mais antigos
param (
  [string]$ResourceGroup = "rg-producao",
  [int]$RetentionDays = 30
)

Connect-AzAccount -Identity

$vms = Get-AzVM -ResourceGroupName $ResourceGroup

foreach ($vm in $vms) {
  foreach ($disk in $vm.StorageProfile.DataDisks) {
    $diskObj = Get-AzDisk -ResourceGroupName $ResourceGroup -DiskName $disk.Name

    # Criar snapshot incremental
    $snapConfig = New-AzSnapshotConfig `
      -Location $diskObj.Location `
      -CreateOption Copy `
      -Incremental `
      -SourceResourceId $diskObj.Id

    $snapName = "$($disk.Name)-snap-$(Get-Date -Format 'yyyyMMdd')"
    New-AzSnapshot -ResourceGroupName "rg-backups" -SnapshotName $snapName -Snapshot $snapConfig
    Write-Output "Snapshot criado: $snapName"
  }
}

# Deletar snapshots mais antigos que $RetentionDays
$cutoffDate = (Get-Date).AddDays(-$RetentionDays)
$oldSnapshots = Get-AzSnapshot -ResourceGroupName "rg-backups" |
  Where-Object { $_.TimeCreated -lt $cutoffDate }

foreach ($snap in $oldSnapshots) {
  Remove-AzSnapshot -ResourceGroupName "rg-backups" -SnapshotName $snap.Name -Force
  Write-Output "Snapshot removido: $($snap.Name)"
}

Azure Policy para enforçar tipos de disco

# Negar criação de discos HDD padrão em ambiente de produção
az policy assignment create \
  --name "deny-standard-hdd-prod" \
  --display-name "Proibir Standard HDD em producao" \
  --policy "11ac78e3-31dc-4ccb-a61a-1cde2a38a2a0" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao" \
  --params '{"listOfAllowedSKUs": {"value": ["Premium_LRS", "StandardSSD_LRS", "UltraSSD_LRS"]}}'

13. Resumo Final

Pontos essenciais:

Managed Disks são objetos ARM independentes da VM, persistentes e replicados pelo Azure
Existem quatro tipos por performance: Ultra Disk (máximo), Premium SSD v2, Premium SSD (mais comum em produção), Standard SSD e Standard HDD (arquivamento)
O caching de disco tem três modos: None, ReadOnly e ReadWrite; use None para logs de banco de dados para evitar perda de dados
Discos de dados podem ser adicionados e removidos sem parar a VM; disco de SO geralmente requer desalocação para expansão
Expansão de disco é irreversível: discos não podem ser reduzidos de tamanho
Snapshots incrementais capturam apenas blocos alterados e são muito mais econômicos para uso recorrente que snapshots full
A opção deleteOption determina se o disco é deletado ou preservado quando a VM é removida; padrão para discos de dados é Detach

Diferenças críticas:

Managed Disk vs. Temporary Disk: Managed é persistente e independente; Temporary é efêmero e perdido em toda desalocação
Full Snapshot vs. Incremental Snapshot: Full copia o disco inteiro; Incremental copia apenas blocos alterados desde o último snapshot
Detach vs. Delete: Detach desconecta o disco mas o preserva como recurso; Delete remove permanentemente
Caching ReadOnly vs. ReadWrite: ReadOnly é seguro para maioria dos workloads; ReadWrite pode causar perda de dados em falha de host se a aplicação não for journal-safe

O que precisa ser lembrado para o AZ-104:

O sufixo do SKU de disco: Premium_LRS, StandardSSD_LRS, Standard_LRS (HDD), UltraSSD_LRS
Comando para expandir: az disk update --size-gb (depois estender partição no OS)
Comando para adicionar disco: az vm disk attach
Comando para remover disco: az vm disk detach (desmontar no OS primeiro)
Número máximo de discos de dados por VM: até 64, dependendo do SKU
Snapshots incrementais são recomendados para uso recorrente de backup
Discos com managedBy == null são órfãos e continuam gerando custo
Ultra Disk requer que o SKU da VM suporte UltraSSDAvailable e que esteja em uma Availability Zone

1. Intuição Inicial​

2. Contexto​

Tipos de armazenamento associados a VMs​

Por que discos são objetos independentes da VM​

3. Construção dos Conceitos​

3.1 Tipos de disco por performance​

3.2 Nomenclatura dos discos Premium SSD​

3.3 Caching de disco​

3.4 Shared Disks (discos compartilhados)​

3.5 Snapshots​

3.6 Disk Bursting​

4. Visão Estrutural​

Estrutura completa de discos em uma VM​

Ciclo de vida de um disco de dados​

5. Funcionamento na Prática​

Expandir um disco (operação crítica e não reversível)​

Adicionar disco de dados sem parar a VM​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

7. Controle e Segurança​

Criptografia de discos​

Backup de discos com Azure Backup​

8. Tomada de Decisão​

Escolha do tipo de disco​

Full snapshot vs. Incremental snapshot​

Cache de disco​

9. Boas Práticas​

10. Erros Comuns​

O erro mais crítico​

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

Inventário e auditoria de discos​

Monitorar performance de discos​

Limites importantes​

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

Política de snapshots automatizados​

Azure Policy para enforçar tipos de disco​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Tipos de armazenamento associados a VMs

Por que discos são objetos independentes da VM

3. Construção dos Conceitos

3.1 Tipos de disco por performance

3.2 Nomenclatura dos discos Premium SSD

3.3 Caching de disco

3.4 Shared Disks (discos compartilhados)

3.5 Snapshots

3.6 Disk Bursting

4. Visão Estrutural

Estrutura completa de discos em uma VM

Ciclo de vida de um disco de dados

5. Funcionamento na Prática

Expandir um disco (operação crítica e não reversível)

Adicionar disco de dados sem parar a VM

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

7. Controle e Segurança

Criptografia de discos

Backup de discos com Azure Backup

8. Tomada de Decisão

Escolha do tipo de disco

Full snapshot vs. Incremental snapshot

Cache de disco

9. Boas Práticas

10. Erros Comuns

O erro mais crítico

11. Operação e Manutenção

Inventário e auditoria de discos

Monitorar performance de discos

Limites importantes

12. Integração e Automação

Política de snapshots automatizados

Azure Policy para enforçar tipos de disco

13. Resumo Final