Laboratório de Troubleshooting: Create and configure a backup policy
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que VMs de produção em uma assinatura do Azure não estão gerando pontos de recuperação há 48 horas. O alerta chegou pela manhã, mas o último backup bem-sucedido registrado no vault data de dois dias atrás.
O administrador acessa o Recovery Services Vault e observa o seguinte no portal:
Vault: vault-prod-brazilsouth
Região: Brazil South
Tipo de replicação: Geo-Redundant Storage (GRS)
Itens de Backup: 12 VMs associadas
Status dos jobs (últimas 48h):
VM-APP-01 | Falha | Error: UserErrorVmNotInDesiredState
VM-APP-02 | Falha | Error: UserErrorVmNotInDesiredState
VM-DB-01 | Falha | Error: UserErrorVmNotInDesiredState
VM-DB-02 | Falha | Error: UserErrorVmNotInDesiredState
(padrão repetido para todas as 12 VMs)
O administrador nota que todas as VMs estão listadas como Running no portal do Azure. O vault foi criado há 6 meses e funcionava normalmente até dois dias atrás. A equipe de infraestrutura informa que, na mesma data, foi aplicado um bloqueio de recurso do tipo ReadOnly no grupo de recursos que contém as VMs, como parte de um processo de governança.
A redundância do vault foi alterada de LRS para GRS três semanas antes do incidente, sem impacto nos backups na época.
Qual é a causa raiz da falha nos jobs de backup?
A) A alteração da redundância do vault de LRS para GRS corrompeu os metadados de associação das VMs, exigindo reconfiguração das políticas.
B) O bloqueio ReadOnly no grupo de recursos das VMs impede que o agente do Azure Backup grave os snapshots e metadados necessários nas VMs durante a execução do job.
C) O erro UserErrorVmNotInDesiredState indica que as VMs estão em estado de deallocated internamente, apesar de aparecerem como Running no portal, o que é um atraso de sincronização conhecido.
D) O vault na região Brazil South sofreu uma degradação de serviço regional que afetou todos os jobs de backup simultaneamente nas últimas 48 horas.
Cenário 2 — Decisão de Ação
A causa de uma falha foi identificada: a política de backup associada a um conjunto de VMs críticas de produção foi configurada com retenção diária de 1 dia, em vez dos 30 dias exigidos pela política de segurança da empresa. Os pontos de recuperação gerados nos últimos 15 dias foram automaticamente excluídos conforme a política incorreta.
O ambiente possui as seguintes restrições:
- As VMs estão em produção ativa e não podem ser desligadas ou reiniciadas
- O Soft Delete está habilitado no vault com janela de 14 dias
- O administrador tem o papel de Backup Contributor na assinatura
- Um comitê de mudanças precisa aprovar alterações em políticas de retenção, mas uma aprovação emergencial pode ser obtida em 2 horas
- O próximo backup agendado ocorre em 4 horas
Qual é a ação correta a tomar neste momento?
A) Desassociar imediatamente as VMs da política incorreta e criar uma nova política com retenção de 30 dias, aplicando-a às VMs antes do próximo backup agendado, sem aguardar aprovação do comitê por se tratar de uma correção, não de uma mudança.
B) Solicitar a aprovação emergencial do comitê de mudanças, editar a política existente para corrigir a retenção para 30 dias e confirmar a alteração antes do próximo backup agendado.
C) Acionar o Soft Delete para recuperar os pontos excluídos nos últimos 14 dias e, em paralelo, editar a política de retenção sem necessidade de aprovação do comitê.
D) Aguardar o próximo backup agendado sem alterar a política, para garantir que o ponto gerado não seja excluído imediatamente, e submeter a mudança ao processo normal do comitê.
Cenário 3 — Causa Raiz
Um administrador tenta configurar o backup de um banco de dados SQL Server hospedado em uma VM do Azure. Ao acessar o vault e clicar em Backup, seleciona SQL in Azure VM como tipo de carga de trabalho e tenta descobrir os bancos de dados na VM VM-SQL-PROD-01.
A operação de descoberta retorna o seguinte erro:
Discovery failed for VM: VM-SQL-PROD-01
Error code: UserErrorSqlInstanceNotFound
Message: No SQL Server instances were found on the virtual machine.
Ensure the SQL Server service is running and the VM agent is healthy.
O administrador verifica:
# Executado via Run Command na VM
> Get-Service -Name MSSQLSERVER
Status Name DisplayName
------ ---- -----------
Running MSSQLSERVER SQL Server (MSSQLSERVER)
> Get-Service -Name WindowsAzureGuestAgent
Status Name DisplayName
------ ---- -----------
Running WindowsAzureGuestAgent Windows Azure Guest Agent
A VM foi migrada de on-premises para o Azure há 30 dias usando o Azure Migrate. O disco de dados onde os arquivos MDF e LDF estão armazenados é um disco gerenciado Premium SSD com 1 TB. A instância SQL Server utiliza uma porta customizada: 1455, diferente da porta padrão 1433. A VM está em uma VNet com NSG que permite tráfego de saída irrestrito.
Qual é a causa raiz da falha na descoberta?
A) O Azure Migrate não prepara a VM corretamente para integração com o Azure Backup, exigindo reinstalação do agente de VM após a migração.
B) O NSG da VNet está bloqueando a comunicação entre o vault e a VM na porta de descoberta, pois o tráfego de saída irrestrito não garante o retorno do tráfego de entrada necessário.
C) A extensão AzureBackupWindowsWorkload não foi instalada na VM, pois o processo de descoberta é o que a instala, e ele falhou antes de concluir a instalação por um problema de conectividade com o endpoint de extensões.
D) O uso de porta customizada 1455 impede que o mecanismo de descoberta do Azure Backup localize a instância SQL Server, pois a descoberta depende de enumeração via porta padrão 1433 ou via WMI/registro do Windows, não via conexão TCP direta.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta às 07:15:
Alerta: Backup job failed
Vault: vault-corp-eastus2
VM: VM-WEB-PROD-07
Erro: ExtensionSnapshotFailedNoNetwork
Horário da falha: 02:35 UTC
Último backup bem-sucedido: 26 horas atrás
O administrador tem os seguintes passos de investigação disponíveis, apresentados fora de ordem:
- Verificar o histórico de jobs do vault para identificar se a falha é isolada a essa VM ou afeta outras VMs no mesmo vault
- Inspecionar os logs da extensão
VMSnapshotdentro da VM para obter detalhes do erro de rede registrados no momento do job - Confirmar se o ponto de recuperação do dia anterior está íntegro e disponível para restauração caso necessário
- Verificar se há regras de NSG ou UDR aplicadas à subnet da VM que possam estar bloqueando o tráfego necessário para o serviço de snapshot
- Confirmar se a extensão
VMSnapshotestá instalada e com status Provisioning succeeded na VM
Qual sequência de diagnóstico representa a abordagem mais eficaz?
A) 3 → 1 → 5 → 2 → 4
B) 1 → 5 → 4 → 2 → 3
C) 5 → 2 → 4 → 1 → 3
D) 1 → 3 → 5 → 4 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
Explicação:
- O bloqueio ReadOnly em um grupo de recursos impede qualquer operação de escrita nos recursos contidos, incluindo as operações que o agente do Azure Backup precisa realizar na VM durante a criação do snapshot: gravação de metadados, coordenação com o VSS e comunicação com o fabric. O erro
UserErrorVmNotInDesiredStateé gerado quando o serviço de backup não consegue colocar a VM no estado necessário para o snapshot, o que ocorre quando operações de escrita são bloqueadas. - A pista definitiva no enunciado é a coincidência temporal exata: o bloqueio ReadOnly foi aplicado na mesma data do último backup bem-sucedido, e todas as 12 VMs falharam simultaneamente com o mesmo código de erro.
- A informação sobre a alteração de LRS para GRS é propositalmente irrelevante: ela ocorreu três semanas antes sem qualquer impacto, e a redundância do vault não afeta a execução dos jobs.
- A alternativa C é o distrator mais perigoso: o código de erro sugere problema de estado da VM, e um administrador menos experiente poderia perseguir um problema inexistente nas VMs em vez de examinar as restrições de governança aplicadas ao grupo de recursos.
Gabarito — Cenário 2
Resposta: B
Explicação:
- O cenário apresenta uma restrição explícita e não negociável: alterações em políticas de retenção requerem aprovação do comitê de mudanças, com opção de aprovação emergencial em 2 horas. O próximo backup ocorre em 4 horas. Há tempo suficiente para seguir o processo correto antes que o próximo ponto seja gerado e potencialmente retido pelo prazo incorreto.
- A alternativa A representa a ação tecnicamente correta, mas aplicada ignorando uma restrição de processo crítica. Em ambientes corporativos regulados, contornar o processo de mudança, mesmo com boas intenções, pode gerar não conformidades auditáveis.
- A alternativa C demonstra um equívoco sobre o Soft Delete: esse recurso mantém dados excluídos por 14 dias após a solicitação de exclusão pelo operador, e não recupera pontos que foram excluídos automaticamente pela política de retenção configurada. Os pontos dos últimos 15 dias já estão permanentemente perdidos.
- A alternativa D é a mais perigosa: aguardar sem corrigir garante que o próximo ponto gerado seja excluído em 1 dia, perpetuando a exposição ao risco.
Gabarito — Cenário 3
Resposta: D
Explicação:
- O mecanismo de descoberta do Azure Backup para SQL in Azure VM não realiza conexão TCP direta ao SQL Server pela porta de escuta. Ele usa WMI e enumeração do registro do Windows para localizar instâncias SQL instaladas na VM. No entanto, o processo de registro e autenticação do backup com a instância SQL Server depende da porta padrão 1433 para estabelecer a comunicação necessária com o serviço de backup durante a fase de descoberta e proteção.
- As pistas no enunciado que confirmam esse diagnóstico: o serviço SQL está Running, o agente de VM está Running, o NSG permite saída irrestrita, e o único elemento atípico documentado é a porta customizada 1455.
- A informação sobre o disco Premium SSD de 1 TB é propositalmente irrelevante: o tipo e tamanho do disco de dados não afeta o mecanismo de descoberta de instâncias SQL.
- A alternativa A é o distrator baseado na origem da VM (migração com Azure Migrate), que o administrador poderia perseguir desnecessariamente. O Azure Migrate não compromete o agente de VM, conforme confirmado pelo status do serviço.
- Agir com base na alternativa A levaria a reinstalações desnecessárias e tempo perdido sem resolver a causa real.
Gabarito — Cenário 4
Resposta: B
Explicação:
- A sequência correta segue a lógica de escopo → infraestrutura → detalhe → impacto:
- Passo 1: Verificar se o problema é isolado ou generalizado determina o escopo do incidente imediatamente e influencia todos os passos seguintes. Um problema generalizado aponta para o vault ou a rede; um problema isolado aponta para a VM específica.
- Passo 5: Confirmar se a extensão está instalada e saudável é o pré-requisito para qualquer diagnóstico mais profundo na VM.
- Passo 4: Com a extensão confirmada como saudável, investigar NSG e UDR é o próximo passo lógico dado o código de erro
ExtensionSnapshotFailedNoNetwork, que aponta explicitamente para falha de rede. - Passo 2: Inspecionar os logs da extensão dentro da VM fornece o detalhe técnico que confirma ou refina o diagnóstico de rede.
- Passo 3: Confirmar a integridade do último ponto de recuperação é uma verificação de impacto e contingência, não um passo de diagnóstico. Deve ser o último passo.
- A alternativa A coloca a verificação de contingência (passo 3) como primeira ação, o que representa uma inversão de prioridades: antes de verificar se há dados para recuperar, é necessário entender e resolver a causa da falha.
- A alternativa C começa pela extensão na VM sem antes verificar o escopo, o que pode levar a diagnóstico detalhado de um problema que afeta todo o vault, desperdiçando tempo.
Árvore de Troubleshooting: Create and configure a backup policy
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial, ponto de entrada |
| Azul médio | Pergunta diagnóstica de decisão |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou validação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se o problema é um job falhando, pontos de recuperação com comportamento inesperado, item não aparecendo como protegível ou vault não podendo ser excluído. Siga as perguntas de diagnóstico respondendo objetivamente com base no que você consegue observar no portal ou nos logs. Cada ramificação elimina hipóteses progressivamente até chegar a uma causa nomeada e uma ação concreta. Nunca pule uma pergunta de verificação intermediária: elas existem para evitar que você aplique a ação correta sobre a causa errada.