Laboratório de Troubleshooting: Create a Recovery Services vault
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador relata que, ao tentar configurar o backup de uma VM pelo portal do Azure, o Recovery Services vault criado previamente não aparece na lista de vaults disponíveis para seleção. A VM está em execução e sem alertas de saúde. O administrador confirma que possui a role Contributor na assinatura.
Informações coletadas:
- Nome do vault:
vault-prod-eastus - Região do vault:
East US 2 - Nome da VM:
vm-app-prod-01 - Região da VM:
East US - Resource group do vault:
rg-backup - Resource group da VM:
rg-compute - Tipo de replicação configurado no vault:
GRS - Soft delete: habilitado
O administrador verifica os logs de atividade e não encontra nenhum erro de permissão ou falha de API.
Qual é a causa raiz do problema?
A) O vault está em um resource group diferente da VM, o que impede a associação entre eles.
B) O vault e a VM estão em regiões diferentes, tornando o vault invisível para essa VM no fluxo de configuração de backup.
C) A replicação GRS está bloqueando o registro de novos recursos até que a configuração seja confirmada.
D) O soft delete habilitado impede o registro de VMs que nunca foram protegidas anteriormente.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que o Recovery Services vault vault-dr-westeu foi criado com replicação LRS, mas a política de compliance da empresa exige GRS para todos os vaults que protegem cargas de trabalho críticas. O vault tem 14 dias de existência e ainda não possui nenhum item protegido configurado.
O gerente de operações solicita resolução imediata. O ambiente de produção está ativo e o vault precisa estar em conformidade antes da auditoria programada para daqui a 48 horas.
Qual é a ação correta a tomar neste momento?
A) Excluir o vault e recriar com GRS, pois nenhum dado foi perdido dado que não há itens protegidos.
B) Alterar a configuração de replicação diretamente no vault de LRS para GRS pelo portal ou CLI, aproveitando que nenhum item está protegido.
C) Criar um novo vault com GRS em paralelo e migrar os itens protegidos existentes para ele.
D) Abrir um ticket no suporte da Microsoft para solicitar a alteração da redundância, pois essa configuração não é editável pelo cliente.
Cenário 3 — Causa Raiz
Durante uma revisão de segurança, o time de operações tenta excluir um Recovery Services vault que não é mais utilizado. O vault aparentemente está vazio. Ao executar o comando de exclusão, o seguinte erro é retornado:
ERROR: Vault cannot be deleted as there are existing resources within the vault.
Please ensure backup is stopped with delete data for all backup items,
and also delete all private endpoints and backup policies for the vault.
(Code: ResourceInUse)
O administrador verifica o portal e confirma que não há VMs, file shares ou outros itens aparecendo como ativamente protegidos. O vault foi criado há seis meses e teve backups ativos que foram interrompidos três semanas atrás via opção "Stop backup". O ambiente usa a configuração padrão de segurança do vault.
Qual é a causa raiz da falha na exclusão?
A) O vault possui políticas de backup personalizadas que precisam ser excluídas antes do vault.
B) Há itens de backup no estado retido com dados, resultantes de interrupção de backup sem exclusão dos dados, e o soft delete mantém os dados por um período adicional após a interrupção.
C) O erro indica que existem private endpoints associados ao vault que não foram removidos antes da tentativa de exclusão.
D) O vault não pode ser excluído porque a replicação GRS mantém uma cópia ativa na região emparelhada que precisa ser removida primeiro.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o relato de que um Recovery Services vault recém-criado não está aceitando o registro de uma VM para backup. Nenhuma mensagem de erro clara foi fornecida pelo usuário que relatou o problema.
Os passos de investigação disponíveis estão fora de ordem:
- Verificar se há itens já protegidos no vault que possam indicar conflito de configuração.
- Confirmar se o vault e a VM estão na mesma região do Azure.
- Verificar se o usuário que tenta configurar o backup possui permissão adequada no vault e na VM.
- Confirmar se o vault foi criado com sucesso e está no estado Active no portal.
- Tentar registrar a VM pelo Azure CLI para isolar se o problema é de interface ou de plataforma.
Qual é a sequência correta de investigação para este cenário?
A) 4 → 2 → 3 → 1 → 5
B) 3 → 4 → 1 → 2 → 5
C) 2 → 4 → 3 → 1 → 5
D) 1 → 3 → 2 → 4 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na comparação entre as regiões: o vault está em East US 2 e a VM está em East US. Essas são regiões distintas no Azure. O portal filtra automaticamente os vaults disponíveis para exibir apenas os que estão na mesma região do recurso sendo protegido. Por isso, o vault simplesmente não aparece na lista, sem gerar nenhuma mensagem de erro explícita.
A informação sobre o resource group diferente (A) é o distrator propositalmente irrelevante deste cenário. O vault e a VM podem estar em resource groups completamente distintos sem qualquer impacto na capacidade de associação para backup. Esse é um equívoco comum, especialmente em ambientes onde existe uma política de separar recursos por grupos.
O tipo de replicação (C) e o soft delete (D) não possuem nenhuma relação com visibilidade ou elegibilidade de registro. Agir com base em (A) levaria o administrador a reorganizar resource groups sem resolver o problema real, desperdiçando tempo crítico.
Gabarito — Cenário 2
Resposta: B
A condição que torna a alternativa B correta é exatamente a ausência de itens protegidos. A configuração de replicação de armazenamento de um Recovery Services vault pode ser alterada diretamente enquanto nenhum item estiver protegido, o que é precisamente o estado atual do vault. Essa é a janela de oportunidade que o cenário apresenta.
A alternativa A descreve uma ação tecnicamente possível, mas desnecessária e mais arriscada: excluir e recriar um vault funcional quando a edição direta está disponível viola o princípio de menor intervenção necessária.
A alternativa C contém um erro factual embutido: o enunciado declara que não há itens protegidos, tornando a premissa de "migrar itens" inválida. Esse distrator força o leitor a verificar se realmente absorveu o estado do ambiente antes de agir.
A alternativa D é incorreta: a alteração de redundância enquanto o vault está vazio é uma operação self-service disponível diretamente ao cliente, sem necessidade de suporte da Microsoft.
Gabarito — Cenário 3
Resposta: B
A causa raiz é a combinação de dois comportamentos relacionados: os backups foram interrompidos via "Stop backup" sem a opção de excluir os dados retidos, e o soft delete padrão do vault mantém esses dados por 14 dias adicionais após a interrupção. Para o Azure, esses itens ainda existem no vault, mesmo que não apareçam como ativamente protegidos na visualização padrão do portal.
A pista crítica está na frase "interrompidos via opção Stop backup" combinada com "configuração padrão de segurança do vault", que confirma que o soft delete está ativo.
A alternativa C é o distrator mais perigoso: o erro menciona explicitamente private endpoints, e um administrador apressado poderia ir direto investigar endpoints sem questionar a premissa. Porém, o enunciado não descreve nenhum contexto de rede privada ou configuração de private endpoint, tornando essa hipótese menos fundamentada do que a presença de dados retidos.
A alternativa A descreve um passo adicional que pode ser necessário, mas não é a causa raiz da falha de exclusão neste cenário. A alternativa D confunde replicação de armazenamento com bloqueio de exclusão, o que não tem fundamento no comportamento real do serviço.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 4 → 2 → 3 → 1 → 5, que representa o raciocínio diagnóstico progressivo do mais fundamental para o mais específico.
O passo 4 vem primeiro porque confirmar que o vault existe e está operacional é a verificação de base. Sem isso, qualquer investigação subsequente carece de fundamento. O passo 2 vem a seguir por ser a causa mais comum e objetivamente verificável de falha no registro de VMs em vaults. O passo 3 investiga permissões, que é uma causa frequente, mas que só faz sentido verificar após confirmar que a infraestrutura básica está correta. O passo 1 verifica conflitos de configuração, que são menos prováveis em vaults novos. O passo 5 encerra como isolamento de camada, para determinar se o problema é de interface ou de plataforma, e só faz sentido após esgotar as hipóteses de configuração.
A sequência B começa por permissões, o que é um erro de triagem: permissões são relevantes, mas verificar infraestrutura antes de identidade é a ordem correta em diagnósticos de registro de recursos. A sequência C começa pela região, pulando a verificação de existência do vault, que é mais elementar. A sequência D começa por conflitos em itens existentes, o que é o passo de menor probabilidade em um vault recém-criado.
Árvore de Troubleshooting: Create a Recovery Services vault
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, parta sempre do nó raiz descrevendo o sintoma observado e siga as ramificações respondendo objetivamente cada pergunta de diagnóstico. Cada resposta elimina um conjunto de hipóteses e conduz ao próximo nível de verificação. O objetivo é chegar a um nó de causa identificada com o menor número de passos possível, sem pular etapas de validação intermediária. Quando a causa estiver confirmada, o nó de ação correspondente indica a resolução direta, sem ambiguidade.