Laboratório de Troubleshooting: Perform Backup and Restore Operations by Using Azure Backup
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que os backups de uma VM crítica pararam de ser executados há 6 dias. A VM continua em funcionamento normal, sem incidentes de rede ou falhas de disco relatados. O Recovery Services Vault está na mesma região da VM, com status Active no portal.
O administrador verifica o histórico de jobs no vault e encontra o seguinte:
Backup Job History — Last 7 days
Date Status Duration Error Code
2026-03-20 Completed 00:42:11 —
2026-03-21 Failed 00:00:03 UserErrorVmNotInDesiredState
2026-03-22 Failed 00:00:03 UserErrorVmNotInDesiredState
2026-03-23 Failed 00:00:03 UserErrorVmNotInDesiredState
2026-03-24 Failed 00:00:03 UserErrorVmNotInDesiredState
2026-03-25 Failed 00:00:03 UserErrorVmNotInDesiredState
2026-03-26 Failed 00:00:03 UserErrorVmNotInDesiredState
O administrador também confirma que:
- A política de backup está configurada para execução diária às 02:00 UTC
- O vault tem replicação GRS habilitada
- A VM tem um disco de dados de 2 TB adicionado recentemente
- A assinatura não atingiu nenhum limite de cota de armazenamento
Qual é a causa raiz da falha nos backups?
A) O disco de dados de 2 TB adicionado à VM excede o limite suportado pelo Azure Backup para discos individuais, bloqueando a execução do job.
B) A VM está em um estado que impede a execução do backup, como Deallocated ou Stopped (deallocated), apesar de o sistema operacional parecer acessível por outros meios.
C) A replicação GRS habilitada no vault está causando conflito com a execução de backups durante a janela de replicação geográfica.
D) A política de backup foi corrompida após a adição do disco de dados, exigindo recriação da associação entre a VM e o vault.
Cenário 2 — Decisão de Ação
A causa de um problema foi identificada: um administrador excluiu acidentalmente o item de backup de uma VM de produção diretamente no Recovery Services Vault. A exclusão ocorreu há 9 dias. O vault tem o recurso de Soft Delete habilitado.
O ambiente possui as seguintes características relevantes:
- A VM original ainda está em execução e íntegra
- O último backup bem-sucedido antes da exclusão foi realizado há 11 dias
- A organização exige que o RPO máximo para essa VM seja de 24 horas
- Um novo backup foi configurado imediatamente após a descoberta do incidente, há 2 horas
- O time de segurança está monitorando o caso e aguarda confirmação de que os dados históricos foram preservados
Dado que a causa foi identificada e o ambiente está descrito acima, qual é a ação correta a tomar neste momento?
A) Iniciar imediatamente a restauração da VM a partir do ponto de recuperação disponível no estado de soft delete, sobrescrevendo a VM de produção atual.
B) Reativar o item de backup no estado de soft delete para recuperar o acesso aos pontos de recuperação históricos, sem interromper a VM em produção.
C) Aguardar o próximo backup agendado ser concluído antes de qualquer ação, pois a VM original está íntegra e não há perda de dados ativa.
D) Excluir permanentemente o item em soft delete e recriar a proteção do zero, pois os dados têm 11 dias e violam o RPO de 24 horas de qualquer forma.
Cenário 3 — Causa Raiz
Um administrador tenta realizar a restauração de arquivos individuais de uma VM Linux usando a funcionalidade de File Recovery do Azure Backup. O ponto de recuperação selecionado tem 3 dias de idade. O script de montagem foi gerado com sucesso no portal e executado na VM de destino.
A saída do script na VM de destino é a seguinte:
$ sudo bash ILRscript.sh
Connection to recovery point established.
Mounting recovery volumes...
ERROR: Mount failed for volume /dev/sdc1
Filesystem type: XFS
Kernel module: xfs — not loaded
Please ensure the required filesystem modules are available on this machine.
Recovery point connection will expire in: 11:47:32
O administrador verifica que:
- A VM de destino é Ubuntu 22.04 com kernel 5.15
- A VM de origem onde o backup foi feito é Red Hat Enterprise Linux 8.6
- A rede entre as VMs e o vault não apresenta bloqueios
- O grupo de recursos da VM de destino está na mesma região do vault
- O disco de SO da VM de origem usa sistema de arquivos XFS
Qual é a causa raiz da falha na montagem?
A) O script de montagem expirou durante a execução devido a latência de rede entre a VM de destino e o vault, impedindo o estabelecimento do volume iSCSI.
B) O módulo de kernel para o sistema de arquivos XFS não está carregado na VM de destino, que usa uma distribuição diferente da VM de origem.
C) A restauração de arquivos individuais não é suportada entre VMs de distribuições Linux diferentes, sendo necessário restaurar o disco completo.
D) O ponto de recuperação de 3 dias não está disponível para File Recovery porque apenas pontos criados nas últimas 24 horas suportam montagem iSCSI.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta indicando que o backup de uma VM Windows falhou com o erro GuestAgentSnapshotTaskTimedOut. A VM é usada como servidor de aplicação em produção e os backups estavam funcionando normalmente até 48 horas atrás. Nenhuma alteração de infraestrutura foi registrada no changelog da equipe.
Os passos de investigação disponíveis são:
[P] Verificar o status e a versão do Azure VM Agent instalado na VM
[Q] Confirmar se a política de backup foi modificada nas últimas 48 horas
[R] Verificar se há snapshots pendentes ou travados no disco da VM via portal
[S] Analisar os logs do Windows Event Viewer na VM para erros do agente de guest
[T] Verificar conectividade da VM com os endpoints do Azure Backup (URLs de serviço)
Qual é a sequência correta de investigação para esse erro?
A) T, Q, P, S, R
B) Q, T, R, P, S
C) P, T, S, R, Q
D) R, P, T, S, Q
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O código de erro UserErrorVmNotInDesiredState indica diretamente que a VM não está no estado operacional esperado pelo Azure Backup no momento da execução do job. Esse erro ocorre quando a VM está em estado Deallocated ou Stopped (deallocated), pois o Azure Backup Application Consistent Backup requer que o agente de guest esteja em execução para coordenar os snapshots com consistência.
A pista decisiva no enunciado é que o erro ocorre com duração de apenas 3 segundos em todos os dias, o que indica rejeição imediata antes de qualquer tentativa de snapshot, característica de verificação de estado da VM antes da execução.
A informação irrelevante é o disco de dados de 2 TB adicionado recentemente. Embora seja um detalhe técnico saliente, o Azure Backup suporta discos de até 32 TB e o erro não tem relação com tamanho de disco. A inclusão desse detalhe testa a tendência de correlacionar a mudança mais recente com a falha, sem evidência.
A replicação GRS (alternativa C) é uma configuração do vault que não interfere na execução de jobs de backup. A alternativa D é implausível porque a associação entre VM e vault não é afetada pela adição de discos.
Agir com base na alternativa A levaria o administrador a remover o disco de dados ou reconfigurar políticas de disco sem resolver o problema real, prolongando a janela de exposição sem backup.
Gabarito — Cenário 2
Resposta: B
O item de backup está em estado de soft delete há 9 dias. O período de retenção do soft delete é de 14 dias, portanto os dados históricos ainda estão acessíveis e dentro do prazo. A ação correta é reativar (undelete) o item, o que restaura o acesso a todos os pontos de recuperação sem nenhuma perda de dados e sem impacto na VM de produção em execução.
A alternativa A é incorreta no contexto: a VM original está íntegra, e sobrescrever a produção com um ponto de recuperação de 11 dias causaria perda de dados dos últimos 11 dias sem nenhuma necessidade operacional.
A alternativa C ignora a restrição de RPO: mesmo que a VM esteja íntegra hoje, a organização exige histórico de backup com RPO de 24 horas. Aguardar o próximo backup não resolve o gap histórico nem confirma ao time de segurança que os dados anteriores foram preservados.
A alternativa D é o distrator mais perigoso. O raciocínio de que "os dados têm 11 dias e violam o RPO de qualquer forma" é falso porque o RPO de 24 horas se refere ao objetivo de frequência de backups futuros, não a um critério para descartar dados históricos existentes. Excluir permanentemente um item em soft delete é irreversível.
Gabarito — Cenário 3
Resposta: B
A saída do script é explícita: Kernel module: xfs — not loaded. O volume a ser montado usa sistema de arquivos XFS, que é nativo em distribuições como Red Hat Enterprise Linux, mas não está carregado por padrão no Ubuntu 22.04. O script de montagem estabeleceu a conexão com sucesso com o ponto de recuperação, mas falhou ao tentar montar o volume localmente por ausência do módulo de kernel.
A solução direta é carregar o módulo com sudo modprobe xfs e executar o script novamente dentro do prazo de validade de 12 horas.
A alternativa A é refutada diretamente pelo log: Connection to recovery point established confirma que a conexão iSCSI foi bem-sucedida. O timer mostrando 11h47m restantes também descarta expiração como causa.
A alternativa C é um equívoco conceitual comum: o File Recovery suporta restauração entre distribuições Linux distintas, desde que o sistema de arquivos esteja acessível na VM de destino.
A alternativa D é falsa: a janela de disponibilidade para File Recovery não é limitada a 24 horas. O que tem validade de 12 horas é o script de montagem após sua geração, não o ponto de recuperação em si.
A informação irrelevante é a localização do grupo de recursos da VM de destino na mesma região do vault, que é um requisito de suporte ao File Recovery já atendido e não tem relação com a falha observada.
Gabarito — Cenário 4
Resposta: C
A sequência correta é P, T, S, R, Q, que segue a lógica de diagnóstico progressivo para o erro GuestAgentSnapshotTaskTimedOut:
-
P — Verificar o status e versão do Azure VM Agent é o primeiro passo porque o erro nomeia explicitamente o agente de guest como componente envolvido. Um agente desatualizado, parado ou corrompido é a causa mais frequente desse erro.
-
T — Se o agente está saudável, o próximo passo é verificar conectividade com os endpoints do Azure Backup, pois o agente depende de comunicação com URLs específicas para coordenar snapshots.
-
S — Com conectividade confirmada, analisar os logs do Event Viewer aprofunda o diagnóstico dentro da VM, buscando erros específicos do agente ou do VSS.
-
R — Verificar snapshots pendentes ou travados é um passo de validação intermediária após os logs, pois snapshots acumulados podem bloquear novas tentativas.
-
Q — Verificar modificações na política de backup é o último passo porque o enunciado já informa que nenhuma alteração de infraestrutura foi registrada, tornando essa hipótese menos prioritária, mas ainda válida para descarte formal.
A sequência da alternativa A (T, Q, P, S, R) erra ao priorizar a verificação de política antes do agente, ignorando a pista direta que o nome do erro fornece. A alternativa B começa pela política, que o enunciado já sinalizou como improvável. A alternativa D começa por snapshots travados, que são uma consequência possível, não uma causa raiz inicial.
Árvore de Troubleshooting: Perform Backup and Restore Operations by Using Azure Backup
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | 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 identificando se a falha está no job de backup ou em uma operação de restore. A partir daí, siga as perguntas fechadas respondendo apenas com o que você consegue observar diretamente no portal ou nos logs. Os nós laranjas indicam que você precisa confirmar um estado antes de prosseguir. Ao atingir um nó vermelho, você chegou à causa; o nó verde imediatamente derivado indica a ação corretiva correspondente.