Laboratório de Troubleshooting: Configure backup for an App Service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador relata que os backups automáticos de um App Service pararam de ser gerados há três dias. O App Service está em um plano Standard S2, hospeda uma aplicação .NET em produção e está vinculado a um banco de dados Azure SQL. A aplicação continua respondendo normalmente a todas as requisições.
O administrador verifica o histórico de backups no portal e encontra a seguinte mensagem de erro repetida nos três últimos agendamentos:
Backup failed: Unable to access the storage destination.
StorageErrorCode: AuthorizationFailure
Container: app-backups
Timestamp: 2025-03-23T02:00:00Z
O administrador informa adicionalmente que:
- A conta de armazenamento existe e o container
app-backupsestá presente - O App Service foi migrado para um novo Resource Group há quatro dias
- A região do Storage Account é diferente da região do App Service
- O plano do App Service não foi alterado
Qual é a causa raiz da falha nos backups?
A) O container de destino foi excluído durante a migração para o novo Resource Group.
B) A SAS URL configurada para o backup expirou ou foi invalidada após a migração para o novo Resource Group.
C) A diferença de região entre o App Service e o Storage Account passou a bloquear o acesso após a migração.
D) O banco de dados Azure SQL vinculado não é mais acessível a partir do novo Resource Group, causando falha no backup completo.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a SAS URL configurada no backup do App Service expirou. O App Service está em produção, recebendo tráfego intenso, e a equipe tem uma janela de manutenção programada para daqui a 48 horas. O backup mais recente válido tem 3 dias de idade.
A equipe debateu as seguintes ações:
- Revogar a SAS atual e gerar uma nova SAS com validade de 2 anos
- Aguardar a janela de manutenção para reconfigurar o backup com a nova SAS
- Acionar uma restauração a partir do backup mais recente para validar a integridade
- Atualizar a configuração de backup com a nova SAS URL imediatamente, sem aguardar a janela
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção de 48 horas para reconfigurar o backup, evitando qualquer alteração em produção fora da janela.
B) Acionar uma restauração a partir do backup de 3 dias para validar se o backup está íntegro antes de qualquer outra ação.
C) Atualizar a configuração de backup com a nova SAS URL imediatamente, sem aguardar a janela de manutenção.
D) Revogar a SAS atual antes de gerar a nova, para garantir que não existam credenciais duplicadas ativas simultaneamente.
Cenário 3 — Causa Raiz
Um administrador recém-contratado tentou configurar backup automático para um App Service e relata que o recurso de backup simplesmente não aparece como opção no menu do portal do Azure. Ele abre um chamado descrevendo o comportamento:
Ambiente:
- App Service Name: webapp-homolog-01
- Plano: B1 (Basic)
- Sistema Operacional: Linux
- Stack: Node.js 20
- Região: East US
- Resource Group: rg-homologacao
Comportamento observado:
A opção "Backups" não aparece no menu lateral do App Service no portal.
Tentei acessar via URL direta e recebi erro 404 no painel de backup.
O administrador também menciona que testou em outros dois App Services da empresa e o menu de backup apareceu normalmente em ambos. Ele verificou que tem a role Contributor no Resource Group. O App Service utiliza um Custom Domain configurado há duas semanas.
Qual é a causa raiz do problema?
A) A role Contributor não é suficiente para acessar a funcionalidade de backup; é necessária a role Owner no Resource Group.
B) App Services com sistema operacional Linux em plano Basic não suportam o recurso de backup nativo do Azure.
C) A configuração de Custom Domain realizada recentemente está bloqueando o acesso ao painel de backup no portal.
D) O plano Basic não oferece suporte ao recurso de backup nativo, independentemente do sistema operacional.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta de que o backup agendado de um App Service falhou. Ele tem acesso ao portal do Azure, ao Storage Account configurado como destino e ao histórico de backups da aplicação. Abaixo estão os passos de investigação disponíveis, apresentados fora de ordem:
[P] Verificar se o plano do App Service suporta backup
[Q] Verificar a mensagem de erro detalhada no histórico de backups do App Service
[R] Tentar executar um backup manual para confirmar se a falha é recorrente
[S] Verificar se a SAS URL está válida e se o container de destino existe e está acessível
[T] Verificar se o banco de dados vinculado está listado corretamente na configuração de backup
Qual é a sequência de diagnóstico mais eficiente e logicamente progressiva?
A) P, Q, S, T, R
B) Q, P, S, T, R
C) S, Q, P, T, R
D) R, Q, S, P, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro AuthorizationFailure indica que o Azure tentou acessar o Storage Account, mas a autorização falhou. O container existe e o Storage Account está acessível, o que descarta exclusão acidental (alternativa A). A causa real é que a SAS URL utilizada na configuração de backup foi invalidada ou expirou. Migrações de Resource Group não invalidam SAS diretamente, mas é comum que, nesse processo, as configurações sejam revisadas e a SAS tenha sido regenerada ou removida sem que o backup fosse atualizado.
A informação sobre a diferença de região entre o Storage Account e o App Service é propositalmente irrelevante: o Azure permite backup cross-region sem restrições, e essa condição existia antes da falha sem causar problemas. A alternativa D é plausível, mas o erro retornado é de autorização no Storage, não de conectividade com o banco de dados; erros de backup de banco vinculado produzem mensagens distintas. O distrator mais perigoso é o A: confirmar que o container existe antes de verificar a validade da SAS pode levar o administrador a perder tempo criando um novo container desnecessariamente.
Gabarito — Cenário 2
Resposta: C
A causa já foi identificada (SAS expirada) e a correção é não destrutiva: atualizar a URL de SAS na configuração de backup não afeta o tráfego da aplicação, não causa downtime e não altera nenhum componente em execução. Aguardar 48 horas (alternativa A) prolonga desnecessariamente o período sem backup válido em um ambiente de produção, o que representa risco operacional real. Acionar uma restauração (alternativa B) seria uma ação destrutiva e desnecessária neste momento, já que o problema não é de integridade do backup, mas de configuração de acesso. Revogar a SAS antes de gerar a nova (alternativa D) criaria uma janela sem configuração válida, tornando o problema ainda pior temporariamente. A restrição crítica do cenário é o risco de continuar sem backup, que supera qualquer argumento para aguardar a janela de manutenção.
Gabarito — Cenário 3
Resposta: D
O plano Basic não oferece suporte ao recurso de backup nativo do App Service, independentemente do sistema operacional ou da stack utilizada. O suporte começa no plano Standard. A ausência do menu no portal é o comportamento esperado para planos não suportados. O fato de o menu aparecer nos outros dois App Services da empresa indica que eles estão em planos superiores, o que é uma pista confirmatória.
A informação sobre o Custom Domain é irrelevante e foi incluída propositalmente para desviar o diagnóstico. Custom Domains não têm nenhuma relação com a disponibilidade do recurso de backup. A alternativa B é o distrator mais refinado: ela mistura dois fatores reais (sistema operacional Linux e plano Basic), mas a restrição determinante é exclusivamente o plano, não o SO. A alternativa A é factualmente incorreta: a role Contributor é suficiente para configurar backups.
Gabarito — Cenário 4
Resposta: B
A sequência correta é Q, P, S, T, R, que segue a lógica diagnóstica progressiva:
- Q — Ler a mensagem de erro detalhada é sempre o primeiro passo; ela direciona todos os demais.
- P — Verificar se o plano suporta backup elimina a causa mais fundamental antes de investigar configurações.
- S — Validar a SAS URL e o container aborda o problema de acesso ao destino, o erro mais frequente em backups estabelecidos.
- T — Verificar o banco vinculado cobre uma causa menos comum, investigada após as mais prováveis.
- R — Executar um backup manual ao final confirma se a correção aplicada resolveu o problema, servindo como validação.
A sequência D (começar pelo backup manual) representa o erro clássico de testar antes de diagnosticar: o backup manual vai falhar pelo mesmo motivo, sem agregar informação nova. A sequência A (começar por P) ignora a mensagem de erro, que já entregaria a direção correta sem custo.
Árvore de Troubleshooting: Configure backup for an App Service
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (raiz) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de uma falha de backup, comece pelo nó raiz e responda cada pergunta com base no que é observável no portal ou nos logs. O primeiro ponto de bifurcação separa problemas de disponibilidade do recurso (plano incompatível) de problemas de execução (configuração inválida). Siga o caminho que corresponde ao que você observa, não ao que você suspeita. Ao chegar a uma ação, execute-a e retorne ao nó de validação antes de encerrar o diagnóstico.