Laboratório de Troubleshooting: Configure and interpret reports and alerts for backups
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador configura o Backup Reports para um Recovery Services vault criado há dois meses. As configurações de diagnóstico do cofre estão ativas e apontam para um Log Analytics Workspace na mesma região. O plano de retenção do workspace está definido para 90 dias.
Ao acessar o Azure Backup Center e navegar até a seção de relatórios, o administrador seleciona o workspace correto no filtro e define o intervalo de tempo como os últimos 60 dias. O dashboard exibe corretamente os dados de jobs e políticas, mas a aba Backup Instances aparece completamente vazia, sem nenhum item listado.
O administrador verifica no portal que existem 14 máquinas virtuais protegidas pelo cofre, todas com backups bem-sucedidos nos últimos 7 dias. O cofre utiliza políticas de backup padrão e não passou por nenhuma alteração recente. A assinatura está ativa e sem alertas de quota.
Informações adicionais coletadas pelo administrador:
Workspace: law-backup-prod-eastus
Cofre : rsv-prod-eastus
Diagnostics settings habilitadas em: 2024-01-15
Data atual: 2024-03-20
Tabelas configuradas:
- CoreAzureBackup
- AddonAzureBackupJobs
- AddonAzureBackupPolicy
- AddonAzureBackupStorage
Qual é a causa raiz da ausência de dados na aba Backup Instances?
A) O workspace está configurado para retenção de 90 dias, o que limita a exibição de instâncias a esse período, ocultando registros mais antigos.
B) A tabela AddonAzureBackupProtectedInstance não foi incluída nas configurações de diagnóstico do cofre.
C) O filtro de intervalo de tempo de 60 dias excede o limite suportado pelo Backup Reports para a aba de instâncias, que é de 30 dias.
D) O Azure Backup Center requer permissão de leitura explícita no nível do workspace para exibir dados de instâncias protegidas, e essa permissão está ausente.
Cenário 2 — Decisão de Ação
A equipe de operações recebeu um alerta crítico às 02h17 indicando falha no backup de uma máquina virtual de produção que executa um banco de dados SQL crítico. A investigação inicial confirmou que a causa é um agente de backup desatualizado instalado na VM, incompatível com a versão atual da extensão do Azure Backup.
O ambiente possui as seguintes restrições no momento:
| Restrição | Detalhe |
|---|---|
| Janela de manutenção | Encerra às 04h00 (falta 1h43) |
| Impacto em produção | VM está ativa e processando transações |
| Último backup bem-sucedido | 22h00 do dia anterior |
| Permissão disponível | Administrador com acesso Contributor na assinatura |
| Política de mudança | Atualizações de agente requerem aprovação do CAB |
Qual é a ação correta a tomar neste momento?
A) Atualizar imediatamente o agente de backup na VM, pois o administrador possui permissão Contributor e a janela de manutenção ainda está aberta.
B) Executar um backup sob demanda via portal do Azure para cobrir o período desde o último backup bem-sucedido, sem alterar o agente, e registrar a ocorrência para tratamento no próximo CAB.
C) Suspender a proteção da VM no cofre, remover a extensão de backup manualmente via SSH e reinstalá-la na versão mais recente dentro da janela de manutenção.
D) Escalar para o CAB de emergência solicitando aprovação para atualizar o agente agora, aguardando resposta antes de qualquer ação.
Cenário 3 — Causa Raiz
Um administrador relata que os alertas de backup configurados no Azure Monitor pararam de ser enviados ao grupo de ações vinculado. A regra de alerta está com status Enabled no portal e não apresenta nenhuma mensagem de erro visível.
O administrador coleta as seguintes informações:
Regra de alerta : alert-backup-unhealthy
Sinal : Backup Health Events
Condição : Health Status = Unhealthy
Grupo de ação : ag-ops-email
Status da regra : Enabled
Último disparo : 8 dias atrás
Ao consultar o grupo de ações diretamente, o administrador verifica:
Grupo de ação : ag-ops-email
Status : Enabled
Ação configurada : Email
Endereço : ops-team@empresa.com
Último uso : 8 dias atrás
O administrador também observa que, nos últimos 8 dias, três VMs apresentaram falhas de backup confirmadas pelo portal do Recovery Services vault, e as falhas estão registradas nos logs do workspace.
O cofre passou por uma migração de resource group há 10 dias, realizada pelo time de infraestrutura para reorganização de recursos.
Qual é a causa raiz do problema?
A) O grupo de ações está com o endereço de e-mail inválido após a migração do resource group, pois recursos vinculados perdem configurações de notificação durante movimentações.
B) A regra de alerta perdeu o vínculo com o Recovery Services vault após a migração entre resource groups, passando a monitorar um escopo inexistente ou incorreto.
C) O sinal Backup Health Events tem um limite de disparo de uma vez a cada 7 dias por design, o que explica a ausência de alertas após o último disparo há 8 dias.
D) O Log Analytics Workspace deixou de receber eventos do cofre após a migração, pois as configurações de diagnóstico são desvinculadas automaticamente durante movimentações de resource group.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe a seguinte reclamação do time de negócio:
"O dashboard de Backup Reports não exibe nenhum dado. Configuramos tudo corretamente na semana passada."
O administrador precisa investigar o problema de forma sistemática. Os passos disponíveis para diagnóstico são:
- Verificar se as configurações de diagnóstico do cofre estão habilitadas e apontando para o workspace correto.
- Confirmar no portal do Recovery Services vault se backups foram executados no período selecionado pelo filtro.
- Consultar as tabelas do workspace via KQL para verificar se há dados ingeridos.
- Verificar se o workspace correto está selecionado no filtro do Backup Reports.
- Confirmar quais tabelas de diagnóstico foram habilitadas nas configurações do cofre.
Qual é a sequência correta de diagnóstico?
A) 2 → 1 → 5 → 3 → 4
B) 4 → 1 → 5 → 3 → 2
C) 1 → 3 → 4 → 5 → 2
D) 4 → 2 → 1 → 5 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A lista de tabelas configuradas nas configurações de diagnóstico não inclui a AddonAzureBackupProtectedInstance, que é exatamente a tabela responsável por alimentar a aba Backup Instances no Backup Reports. Cada aba do relatório depende de uma tabela específica: jobs dependem de AddonAzureBackupJobs, políticas de AddonAzureBackupPolicy, e instâncias protegidas de AddonAzureBackupProtectedInstance. A ausência dessa tabela na configuração faz com que apenas a aba de instâncias fique vazia, enquanto as demais exibem dados normalmente.
A informação sobre a retenção de 90 dias (alternativa A) é o dado irrelevante incluído propositalmente. A retenção controla por quanto tempo os dados são mantidos, não quais dados são coletados. A alternativa C é falsa; não existe limite de 30 dias para a aba de instâncias. A alternativa D é um distrator plausível, mas o enunciado não apresenta nenhum sintoma de erro de permissão, e o administrador consegue visualizar outras abas do mesmo relatório sem problema.
O distrator mais perigoso é a alternativa D: um administrador que atribua permissões adicionais sem verificar as configurações de diagnóstico perderá tempo e não resolverá o problema.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada (agente desatualizado), mas a restrição crítica que determina a ação correta é a política de mudança: atualizações de agente requerem aprovação do CAB. Agir sem aprovação, mesmo com permissão técnica disponível (alternativa A), viola o processo de governança e expõe o administrador a responsabilidade por uma mudança não autorizada em produção.
A ação correta é executar um backup sob demanda, que não altera configurações nem requer aprovação de CAB, garantindo a cobertura do período sem backup enquanto a resolução definitiva segue o rito correto. Isso protege o RPO sem violar restrições processuais.
A alternativa C combina dois problemas: remover a extensão manualmente é uma ação destrutiva e não autorizada, com risco real de interrupção em produção. A alternativa D ignora que existe uma ação imediata de menor risco disponível (o backup sob demanda) enquanto o processo de aprovação ocorre em paralelo, desperdiçando a janela de proteção disponível.
Gabarito — Cenário 3
Resposta: B
A pista decisiva no enunciado é a migração do cofre entre resource groups há 10 dias, exatamente quando os alertas pararam. Regras de alerta do Azure Monitor são configuradas com um escopo que aponta para um recurso por seu Resource ID. Quando um recurso é movido entre resource groups, seu Resource ID muda. A regra de alerta passa a monitorar um ID que não existe mais, tornando-se silenciosamente inoperante sem exibir erros visíveis no portal.
A informação sobre o grupo de ações estar habilitado e com o último uso há 8 dias é o dado irrelevante incluído para desviar o diagnóstico. O grupo de ações funciona corretamente; o problema está no escopo da regra.
A alternativa D é o distrator mais perigoso: é tecnicamente verdade que configurações de diagnóstico podem ser afetadas por movimentações, mas o enunciado informa que falhas de backup estão registradas nos logs do workspace, o que confirma que a ingestão de dados continua funcionando. Isso elimina a alternativa D. A alternativa C descreve um comportamento inexistente na plataforma.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 4 → 1 → 5 → 3 → 2, pois segue a lógica de diagnóstico progressivo do mais superficial ao mais profundo:
Passo 4 primeiro: verificar se o workspace correto está selecionado no filtro elimina o erro mais simples e mais comum sem exigir nenhum acesso técnico adicional.
Passo 1 em seguida: confirmar se as configurações de diagnóstico estão habilitadas e apontando para o workspace certo valida a origem dos dados.
Passo 5: verificar quais tabelas foram habilitadas nas configurações é mais específico que confirmar se elas existem, e deve vir antes de consultar os dados.
Passo 3: consultar as tabelas via KQL confirma empiricamente se os dados estão sendo ingeridos, validando os passos anteriores.
Passo 2 por último: confirmar se backups foram executados no período só faz sentido depois de descartar todos os problemas de configuração e ingestão. Se não há dados no relatório mas há dados no workspace, o problema é de filtragem; se não há dados no workspace, o problema é de ingestão.
A alternativa A comete o erro clássico de ir direto à verificação dos backups antes de validar a infraestrutura de coleta de dados. A alternativa C começa pela fonte técnica antes de eliminar causas simples.
Árvore de Troubleshooting: Configure and interpret reports and alerts for backups
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 |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que é observável no portal ou nos logs. Siga o ramo correspondente à resposta até alcançar um nó vermelho de causa identificada, depois avance para o nó verde de ação. Após executar a ação, passe pelo nó laranja de validação para confirmar que o problema foi resolvido antes de encerrar o incidente.