Laboratório de Troubleshooting: Configure soft delete for blobs and containers
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de dados relatou que um blob crítico foi deletado acidentalmente por um script automatizado na madrugada. O administrador confirma que o soft delete para blobs está habilitado na storage account com retenção de 15 dias. A storage account também tem o versionamento de blobs habilitado e utiliza a camada de acesso Cool.
O administrador executa o seguinte comando para tentar recuperar o arquivo:
az storage blob undelete \
--account-name prodstorageacct \
--container-name datasets \
--name pipeline-output.parquet
A saída retorna sem erro, mas ao listar os blobs do container, o arquivo não aparece:
az storage blob list \
--account-name prodstorageacct \
--container-name datasets \
--output table
Name Blob Type Blob Tier Length Content Type
---------------------- ----------- ----------- -------- ------------
archive-2024.parquet BlockBlob Cool 4823901 application/octet-stream
O administrador verifica no portal do Azure e confirma que o soft delete para blobs está ativo. A política de lifecycle management da conta não possui regras configuradas para o container datasets.
Qual é a causa raiz da ausência do arquivo após a operação de undelete?
A. O comando undelete foi executado com sucesso, mas o blob está na camada Cool e requer reidratação antes de aparecer na listagem.
B. O arquivo foi deletado há mais tempo do que o período de retenção configurado, portanto não existe mais no estado soft-deleted.
C. O comando az storage blob list não exibe blobs restaurados por padrão; é necessário adicionar o parâmetro --include-deleted.
D. O versionamento de blobs está interferindo na operação de undelete, exigindo que a restauração seja feita por versão específica.
Cenário 2 — Decisão de Ação
A causa do problema já foi identificada: o soft delete para containers não estava habilitado em uma storage account de produção. Um container chamado relatorios-fiscais foi deletado acidentalmente por um membro da equipe com acesso de Contributor. A storage account possui soft delete para blobs habilitado com retenção de 30 dias, mas o container e todo o seu conteúdo não podem ser recuperados.
O administrador precisa agir. As seguintes restrições se aplicam:
- A storage account está em produção e outros containers ativos dependem dela
- Existe um backup do container em uma storage account secundária com dados de 48 horas atrás
- A equipe de compliance exige que a recuperação use os dados mais recentes disponíveis
- O administrador possui acesso de Owner na subscription
Qual é a ação correta a tomar neste momento?
A. Deletar e recriar a storage account inteira a partir de um snapshot de Resource Manager para garantir a integridade da restauração.
B. Habilitar imediatamente o soft delete para containers na storage account atual e aguardar que o Azure recupere o container automaticamente.
C. Restaurar o conteúdo do backup na storage account secundária para um novo container na storage account de produção e, em seguida, habilitar o soft delete para containers para prevenir recorrência.
D. Aplicar um resource lock do tipo CanNotDelete na storage account e abrir um chamado de suporte para que a Microsoft restaure o container deletado.
Cenário 3 — Causa Raiz
Um administrador recebe o seguinte alerta no portal do Azure: um container chamado logs-app foi deletado. Ele verifica que o soft delete para containers está habilitado com retenção de 7 dias e tenta recuperar o container via portal. O container aparece na listagem de containers deletados, mas ao clicar em "Undelete", a operação falha com a seguinte mensagem:
ContainerAlreadyExists: The specified container already exists.
O administrador verifica o estado atual da storage account e encontra o seguinte:
az storage container list \
--account-name appstorageacct \
--output table
Name Lease Status Public Access
------------ -------------- -------------
logs-app unlocked None
backups unlocked None
configs unlocked None
A storage account foi migrada para a região Brazil South há 3 semanas. O soft delete para blobs está desabilitado nesta conta.
Qual é a causa raiz da falha na operação de undelete do container?
A. A migração de região causou inconsistência nos metadados de soft delete, corrompendo o registro do container deletado.
B. O soft delete para blobs precisa estar habilitado para que a operação de undelete de containers funcione corretamente.
C. Um container com o mesmo nome já existe na storage account no estado ativo, impedindo a restauração do container soft-deleted.
D. O período de retenção de 7 dias é insuficiente para a região Brazil South; o mínimo exigido é de 14 dias para operações de undelete.
Cenário 4 — Sequência de Diagnóstico
Um administrador é notificado de que blobs em uma storage account estão desaparecendo sem que nenhum membro da equipe tenha executado exclusões manuais. O soft delete para blobs está habilitado com retenção de 10 dias. Os blobs não aparecem nem mesmo na listagem com --include-deleted.
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar se existe uma política de lifecycle management configurada na storage account com regras de delete
- Verificar os logs de diagnóstico do Azure Monitor para identificar qual identidade executou a operação de exclusão
- Confirmar que o soft delete para blobs está habilitado e qual é o período de retenção atual via portal ou CLI
- Verificar se os blobs desaparecidos ainda existem com
az storage blob list --include-deleted - Revisar as permissões de RBAC atribuídas a service principals e identidades gerenciadas com acesso à storage account
Qual é a sequência correta de investigação?
A. 3 → 4 → 2 → 1 → 5
B. 4 → 3 → 1 → 2 → 5
C. 3 → 4 → 1 → 2 → 5
D. 1 → 3 → 4 → 5 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A operação de undelete retornou sem erro, o que significa que o Azure processou o comando, mas não encontrou nenhum blob soft-deleted com aquele nome para restaurar. Quando não há objeto recuperável, o comando não falha com exceção; simplesmente não há efeito. Isso indica que o arquivo foi deletado há mais de 15 dias, ultrapassando o período de retenção, e foi permanentemente removido antes que a equipe percebesse o problema.
A pista central no enunciado é a ausência de qualquer erro na operação de undelete combinada com a ausência do arquivo. Se o objeto existisse no estado soft-deleted, ele apareceria após o undelete.
A informação sobre a camada Cool e o versionamento de blobs são detalhes irrelevantes para este diagnóstico. A camada de acesso não afeta a visibilidade de blobs na listagem. O versionamento não interfere na operação de undelete de blobs sem versão.
A alternativa C representa o erro de raciocínio mais perigoso: o parâmetro --include-deleted serve para listar blobs ainda no estado soft-deleted, não para listar blobs já restaurados. Agir com base nessa hipótese levaria o administrador a continuar buscando um objeto que simplesmente não existe mais.
Gabarito — Cenário 2
Resposta: C
Dado que o container foi permanentemente perdido e os dados mais recentes disponíveis estão no backup de 48 horas atrás, a única ação que atende todas as restrições é restaurar a partir do backup para um novo container na conta de produção e, em seguida, corrigir a lacuna de configuração habilitando o soft delete para containers.
A alternativa B representa o equívoco mais comum neste tipo de cenário: habilitar o soft delete após a exclusão não tem efeito retroativo. O Azure não recupera dados excluídos antes da habilitação da política. Esta é a consequência mais perigosa de escolher essa alternativa, pois o administrador perderia tempo esperando por uma recuperação que nunca ocorrerá.
A alternativa A é tecnicamente destrutiva e desnecessária: recriar a storage account inteira impactaria todos os outros containers ativos que dependem dela. A alternativa D é inviável porque a Microsoft não oferece serviço de recuperação de dados excluídos sem proteção prévia; resource locks impedem exclusões futuras, não restauram dados já perdidos.
Gabarito — Cenário 3
Resposta: C
A mensagem de erro ContainerAlreadyExists é direta: o Azure está tentando restaurar um container com o nome logs-app, mas já existe um container ativo com esse nome na mesma storage account. A listagem de containers confirma isso explicitamente. O soft delete não pode criar um container com nome duplicado sobre um container ativo existente.
A informação sobre a migração para a região Brazil South há 3 semanas é um detalhe irrelevante inserido propositalmente para desviar o raciocínio. Migrações de região não causam inconsistências em metadados de soft delete.
A alternativa B representa um erro conceitual clássico: soft delete para blobs e soft delete para containers são funcionalidades independentes. A ausência de um não bloqueia a operação do outro. A alternativa D é um distrator baseado em restrições regionais fictícias que não existem na plataforma Azure.
O passo correto após identificar a causa é renomear ou deletar o container ativo conflitante antes de executar a operação de undelete, ou aceitar que o container ativo já foi recriado manualmente e não é necessário restaurar o soft-deleted.
Gabarito — Cenário 4
Resposta: C
A sequência correta é 3 → 4 → 1 → 2 → 5.
O raciocínio diagnóstico correto começa pela validação das premissas antes de investigar causas externas. O passo 3 confirma se o soft delete está realmente ativo e com o período de retenção esperado, eliminando a possibilidade de má configuração. O passo 4 verifica se os blobs existem no estado soft-deleted ou foram permanentemente removidos, o que define o caminho seguinte. O passo 1 é o próximo porque a ausência dos blobs mesmo na listagem com --include-deleted sugere fortemente que algo os está deletando e expirando antes da janela de retenção, o que aponta para lifecycle management. O passo 2 usa os logs de diagnóstico para identificar a identidade responsável pelas exclusões. O passo 5 fecha o ciclo revisando permissões de identidades que poderiam estar executando exclusões automatizadas.
A alternativa A inverte os passos 3 e 4, iniciando pela confirmação da configuração antes de observar o estado dos objetos, o que é menos eficiente pois o estado dos blobs já fornece informação diagnóstica imediata. A alternativa D começa pelo lifecycle management sem antes confirmar as premissas de configuração, pulando a validação inicial que pode revelar a causa de forma mais rápida.
Árvore de Troubleshooting: Configure soft delete for blobs and containers
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial ou ponto de entrada |
| Azul médio | Pergunta diagnóstica |
| 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 pelo nó raiz que descreve o sintoma observado e responda cada pergunta de diagnóstico com base no que você consegue verificar diretamente no ambiente. Siga o caminho que corresponde ao estado real observado, sem pular etapas. Nós vermelhos indicam que a causa foi isolada; nós verdes indicam que há uma ação concreta a executar. Se você chegar a um nó laranja, realize a verificação indicada antes de continuar. O objetivo é chegar a um nó de causa ou resolução pelo menor caminho válido, descartando hipóteses a cada bifurcação com base em evidências observáveis.