Laboratório de Troubleshooting: Configure snapshots and soft delete for Azure Files
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de administração recebe uma reclamação: arquivos excluídos há dois dias de um compartilhamento do Azure Files não aparecem como recuperáveis no portal do Azure. O time confirma que a funcionalidade de soft delete foi configurada na conta de armazenamento há três semanas, com período de retenção de 30 dias.
O administrador acessa o portal, navega até o compartilhamento dados-financeiros e não encontra nenhum item em estado de exclusão suave. Ele verifica a conta de armazenamento e obtém a seguinte saída:
az storage account show \
--name stgfinprod \
--resource-group rg-financeiro \
--query "properties.largeFileSharesState"
"Enabled"
Em seguida, verifica o estado do soft delete no nível do serviço de arquivos:
az storage account file-service-properties show \
--account-name stgfinprod \
--resource-group rg-financeiro \
--query "shareDeleteRetentionPolicy"
{
"days": 30,
"enabled": false
}
A conta de armazenamento está na região East US, foi criada há seis meses e utiliza redundância LRS. O compartilhamento foi montado via SMB em servidores Windows. O protocolo NFS não está em uso.
Qual é a causa raiz da ausência de itens recuperáveis?
A. Os arquivos foram excluídos via SMB, e o soft delete só protege exclusões realizadas via API REST.
B. A política de soft delete está configurada com enabled: false, o que significa que o recurso não estava ativo no momento da exclusão.
C. O período de retenção de 30 dias ainda não foi atingido, mas o portal exige uma atualização manual da visualização para exibir os itens.
D. O recurso largeFileSharesState configurado como Enabled desativa automaticamente o soft delete em contas LRS.
Cenário 2 — Sequência de Diagnóstico
Um administrador recebe o seguinte relato: "Eu montei o compartilhamento do Azure Files no Windows e quero acessar um snapshot criado ontem, mas não consigo encontrá-lo em lugar nenhum."
O administrador precisa diagnosticar se o snapshot existe e por que não está visível. Abaixo estão cinco passos de investigação disponíveis:
- Verificar se há snapshots listados via CLI com
az storage share list --include-snapshots - Orientar o usuário a acessar Propriedades > Versões Anteriores na pasta montada
- Confirmar que o compartilhamento está montado corretamente com letra de unidade ativa
- Verificar se o sistema operacional do cliente é Windows e suporta o recurso de versões anteriores via SMB
- Checar se o snapshot foi criado com sucesso consultando sua data e hora no portal do Azure
Qual sequência de diagnóstico representa a ordem correta de investigação?
A. 3 → 1 → 5 → 4 → 2
B. 1 → 5 → 3 → 2 → 4
C. 5 → 1 → 3 → 4 → 2
D. 3 → 4 → 1 → 5 → 2
Cenário 3 — Causa Raiz
Um administrador criou snapshots diários de um compartilhamento do Azure Files durante 30 dias consecutivos. Ao verificar o custo de armazenamento no final do mês, ele nota que o valor cobrado pelos snapshots é aproximadamente igual ao custo do compartilhamento principal, mesmo que os dados do compartilhamento raramente sejam modificados.
O compartilhamento logs-app tem 500 GB de dados. Os arquivos são gravados uma vez e nunca alterados. O administrador executa o seguinte comando para investigar:
az storage share list \
--account-name stglogsprod \
--include-snapshots \
--query "[].{Name:name, Snapshot:snapshot, Quota:properties.quota, Usage:properties.shareUsageBytes}" \
--output table
Name Snapshot Quota Usage
--------- -------------------------- ------- -----------
logs-app (null) 5120 536870912000
logs-app 2024-11-01T02:00:00.000Z 5120 536870912000
logs-app 2024-11-02T02:00:00.000Z 5120 536870912000
...
logs-app 2024-11-30T02:00:00.000Z 5120 536870912000
O campo Usage em cada snapshot retorna o mesmo valor que o compartilhamento ativo. A conta de armazenamento utiliza GPv2 com SKU Standard LRS. O time de desenvolvimento confirma que nenhum arquivo foi excluído ou modificado desde o início do período.
O administrador conclui que os snapshots estão consumindo 30 vezes o tamanho do compartilhamento. Qual é a causa raiz do comportamento observado na saída do comando?
A. Snapshots no Azure Files consomem armazenamento igual ao tamanho total do compartilhamento, independentemente de alterações nos dados.
B. O parâmetro shareUsageBytes retornado pelo comando para snapshots reflete o tamanho acumulado do compartilhamento no momento do snapshot, não o delta incremental armazenado; o custo real é baseado apenas nos blocos diferentes.
C. A conta GPv2 com SKU Standard não suporta snapshots incrementais; esse comportamento é exclusivo de contas Premium.
D. Os arquivos de log continuam sendo gravados em segundo plano por um agente do sistema operacional, causando diferenças reais entre os snapshots.
Cenário 4 — Decisão de Ação
A causa foi identificada: o soft delete de um compartilhamento do Azure Files estava desabilitado quando arquivos críticos foram excluídos. Os arquivos não são recuperáveis por soft delete. O administrador já confirmou que existe um backup do Azure configurado para o compartilhamento, com o último ponto de recuperação de 18 horas atrás, e que existem snapshots manuais criados há 6 horas e há 24 horas.
O ambiente é de produção. Os arquivos excluídos foram modificados pela última vez há 10 horas. A janela de manutenção permitida é de 30 minutos. Restaurar o backup completo do Azure leva em média 45 minutos e substitui todos os arquivos do compartilhamento. Restaurar a partir de um snapshot leva menos de 5 minutos e permite recuperação de arquivos individuais.
Qual é a ação correta a tomar neste momento?
A. Restaurar o backup completo do Azure, pois ele representa o ponto de recuperação mais recente e garante maior integridade dos dados.
B. Restaurar os arquivos individualmente a partir do snapshot criado há 6 horas, pois é o ponto de recuperação mais próximo do momento da exclusão e respeita a janela de manutenção disponível.
C. Habilitar o soft delete imediatamente e aguardar o sistema recuperar automaticamente os arquivos excluídos.
D. Restaurar a partir do snapshot criado há 24 horas, pois ele é anterior à janela de modificação e garante que os arquivos estejam em estado consistente.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída do comando revela explicitamente "enabled": false na política shareDeleteRetentionPolicy. Isso significa que, no momento em que os arquivos foram excluídos, o soft delete estava inativo, independentemente de qualquer outra configuração da conta. Arquivos excluídos enquanto o recurso está desabilitado não são retidos e não podem ser recuperados.
A pista decisiva está na saída do segundo comando, não no primeiro. O campo largeFileSharesState: Enabled é uma informação irrelevante para o diagnóstico: ele controla apenas o suporte a compartilhamentos grandes (acima de 5 TB) e não tem relação alguma com o comportamento do soft delete. Incluí-lo no enunciado simula o ruído real que um administrador encontra em produção.
A alternativa A é factualmente incorreta: o soft delete cobre exclusões via SMB. A alternativa C inventa um comportamento de atualização manual que não existe. A alternativa D descreve uma relação causal que não existe entre largeFileSharesState e soft delete.
O distrator mais perigoso é o D: um administrador que confunde configurações de capacidade com configurações de proteção de dados pode gastar tempo investigando o SKU da conta enquanto a causa real está visível na saída do comando.
Gabarito — Cenário 2
Resposta: A
A sequência correta é 3 → 1 → 5 → 4 → 2, que segue a lógica de diagnóstico progressivo do mais simples para o mais específico.
O raciocínio é: antes de investigar o snapshot em si, é necessário confirmar que o compartilhamento está montado e acessível (passo 3). Em seguida, verificar via CLI se os snapshots existem de fato (passo 1). Se existirem, confirmar qual foi criado e quando (passo 5). Depois, verificar se o sistema operacional do cliente suporta o acesso via Versões Anteriores (passo 4). Somente após todas essas validações faz sentido orientar o usuário sobre como acessar o snapshot corretamente (passo 2).
Iniciar pelo passo 2, como sugerem as alternativas B e D, é um erro comum: orientar o usuário a procurar versões anteriores antes de confirmar que o snapshot existe é diagnosticar antes de validar. A alternativa C começa pelo passo 5 sem antes confirmar a existência do snapshot via CLI, o que inverte a ordem de verificação objetiva para a interpretativa.
Gabarito — Cenário 3
Resposta: B
O campo shareUsageBytes retornado pelo comando az storage share list para snapshots representa o tamanho total do compartilhamento no momento em que o snapshot foi criado, não o tamanho diferencial dos blocos armazenados. Essa é uma característica conhecida da API de listagem: o valor exibido é o tamanho lógico do ponto no tempo, não o custo real de armazenamento incremental.
Como os arquivos nunca foram modificados ou excluídos após a criação do primeiro snapshot, os snapshots subsequentes não armazenam nenhum bloco novo. O custo real de armazenamento dos 29 snapshots adicionais é próximo de zero, porque snapshots são incrementais e capturam apenas as diferenças. A saída do comando não pode ser usada diretamente para calcular o custo de armazenamento de snapshots.
A alternativa A representa o equívoco mais comum e mais perigoso: concluir que snapshots custam o mesmo que o compartilhamento apenas porque o campo de uso exibe o mesmo valor. A alternativa C é factualmente incorreta: snapshots incrementais funcionam em contas Standard GPv2. A alternativa D é a informação irrelevante propositalmente incluída: o enunciado menciona que arquivos são gravados uma vez e nunca alterados, o que deveria eliminar essa hipótese, mas o distrator a reintroduz como causa.
Gabarito — Cenário 4
Resposta: B
A restrição crítica do cenário é a janela de manutenção de 30 minutos. Restaurar o backup completo leva 45 minutos, o que viola essa restrição. O snapshot criado há 6 horas é o ponto de recuperação mais próximo da exclusão que pode ser utilizado dentro da janela disponível, e permite recuperação de arquivos individuais sem substituir o compartilhamento inteiro.
A alternativa A seria tecnicamente correta em um contexto sem restrição de tempo, mas ignora explicitamente a restrição declarada no enunciado. Escolher essa alternativa representa o erro clássico de aplicar a solução certa no contexto errado.
A alternativa C demonstra desconhecimento do comportamento do soft delete: habilitar o recurso após a exclusão não recupera arquivos já perdidos; ele só protege exclusões futuras.
A alternativa D é o distrator mais sofisticado: o snapshot de 24 horas é anterior às modificações dos últimos 10 horas, o que significa que restaurar a partir dele resultaria em perda de dados de trabalho recente, sendo pior do que o snapshot de 6 horas.
Árvore de Troubleshooting: Configure snapshots and soft delete for Azure Files
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou observável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz, que representa o sintoma observado. A cada nó azul, responda a pergunta com base no que você pode verificar diretamente no ambiente, seja pelo portal, pela CLI ou pelo comportamento do cliente. Siga o caminho correspondente à sua resposta até atingir um nó vermelho, que identifica a causa, ou um nó verde, que indica a ação a executar. Nós laranjas indicam que uma verificação intermediária é necessária antes de concluir o diagnóstico.