Microsoft AZ-801: Recuperação de Desastres e Continuidade de Negócios — Guia de estudos

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Faz parte do Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O design de recuperação de desastres (DR) e continuidade de negócios (BC) começa com a quantificação de duas métricas: Objetivo de Tempo de Recuperação (RTO) e Objetivo de Ponto de Recuperação (RPO). O RTO representa a rapidez com que você deve restaurar o serviço; o RPO define quanta perda de dados (em tempo) é aceitável. Esses valores orientam as escolhas de tecnologia, topologia e custo. Um RTO baixo favorece a orquestração e a automação (planos de recuperação do Azure Site Recovery, runbooks e recursos de destino pré-criados). Um RPO baixo favorece a replicação contínua (ASR) ou a confirmação síncrona (SQL Always On), enquanto um RPO mais alto pode depender de backups periódicos (Azure Backup, Windows Server Backup). Grupos de consistência de múltiplas VMs e snapshots consistentes com o aplicativo preservam a integridade transacional entre VMs quando um RPO rigoroso é exigido. A escolha do cofre (Recovery Services vault vs. Backup vault), o design da política de replicação e o agendamento de backup são todos selecionados para atender a esses objetivos sem exceder o orçamento.

Azure Site Recovery: Hyper-V, VMware, orquestração e consistência

O Azure Site Recovery (ASR) fornece replicação contínua e failover/failback orquestrado para VMs VMware, Hyper-V locais (on-premises) e IaaS do Azure.

Proteção do Hyper-V

• Política de replicação: Define o limite de RPO, a retenção de pontos de recuperação e a cadência de snapshots consistentes com o aplicativo. Por exemplo, defina o limite de RPO para 15 minutos, mantenha pontos de recuperação por 24 a 72 horas para reversão a um ponto no tempo (point-in-time) e tire snapshots consistentes com o aplicativo a cada 1 a 4 horas. As políticas controlam a limitação de largura de banda e a compactação; a consistência de múltiplas VMs pode ser habilitada para VMs relacionadas para que seus pontos de recuperação se alinhem.
• Pontos de recuperação: O ASR mantém pontos consistentes com falhas (crash-consistent) continuamente e pontos adicionais consistentes com o aplicativo quando o VSS quiescing é bem-sucedido. A retenção permite que você selecione pontos anteriores para mitigar corrupção lógica ou ransomware.
• Failover de teste: Exercícios não disruptivos validam runbooks, ordem de inicialização e rede. Use uma VNet isolada, forneça valores de entrada de teste (por exemplo, IPs de DNS) e garanta que a resolução de nomes esteja isolada. A replicação de produção continua inalterada, e a limpeza remove os artefatos de teste após a validação. Estabeleça o mapeamento de rede e teste os mapeamentos de NIC com antecedência para evitar conflitos de IP.

Proteção do VMware

• Servidor de configuração: O appliance local (on-premises) que se registra no Recovery Services vault, descobre o inventário do vCenter/ESXi, coordena a replicação e envia os agentes do Mobility Service. É o plano de controle para a proteção do VMware.
• Servidor de processo: Geralmente localizado junto com o servidor de configuração inicialmente; ele realiza o rastreamento de alterações, compactação, criptografia e transferência de dados para o Azure. Servidores de processo de scale-out são adicionados para aumentar a taxa de transferência (throughput) e para posicionar a entrada (ingress) perto dos hosts protegidos para minimizar a latência.
• Servidor de destino mestre: Usado para failback do Azure para o VMware. Ele recebe as alterações replicadas durante a reproteção e fornece uma zona de destino (landing zone) para que você possa restaurar as cargas de trabalho de volta para o vSphere. Dimensione o armazenamento para a taxa de gravação agregada durante o failback e garanta que a taxa de transferência da rede corresponda aos picos das janelas de ressincronização.
• Mobility Service: Instalado em cada VM protegida para capturar alterações de disco. Mantenha as credenciais ou os mecanismos de push atualizados e monitore a saúde do agente no cofre.

Orquestração e consistência

• Planos de recuperação: Runbooks declarativos para DR que definem agrupamentos, ordem de inicialização, etapas de aprovação manual e tarefas de automação. Use runbooks do Azure Automation para reconfigurar NSGs, atualizar registros DNS, aquecer caches de aplicativos ou executar scripts SQL. Atribua grupos lógicos como camadas de “Dados”, “App” e “Web” e insira pausas para validação.
• Runbooks: Automatize tarefas específicas do ambiente, como alternar endpoints do gerenciador de tráfego, escalar dependências de PaaS ou desativar o monitoramento local (on-premises) durante o failover para reduzir alertas falsos. Parametrize-os para failover de teste versus produção.
• Grupos de consistência de múltiplas VMs: Habilite para camadas que compartilham a mesma ordem de escrita (por exemplo, servidor de aplicação e gravador de log do banco de dados). Isso garante um ponto no tempo consistente entre as VMs; troca taxa de transferência (throughput) por correção e deve ser limitado a VMs verdadeiramente interdependentes.

Backup e restauração: Azure Backup (MARS, MABS/DPM), cofres e Windows Server Backup

O Azure Backup oferece proteção point-in-time para workloads locais (on-premises) e do Azure. Escolha o agente e o tipo de cofre corretos com base na workload e nos recursos.

Agente MARS (Microsoft Azure Recovery Services agent)

• Política de backup: Configure até três backups diários com retenção granular (diária/semanal/mensal/anual) no Recovery Services vault. Selecione a redundância de armazenamento (LRS ou GRS) e alinhe a retenção à conformidade enquanto controla o crescimento do cofre. Agende fora do pico de E/S (I/O) e habilite a limitação de rede (network throttling) quando necessário.
• Backup do Estado do Sistema: Suportado com o MARS para Windows Server para proteger AD, registro, COM+ e arquivos de inicialização. Use para recuperação de controlador de domínio (autoritativa/não autoritativa) ou reparo do SO sem um backup completo no nível da imagem.
• Recuperação online: Restaure arquivos/pastas usando Procurar (Browse) ou Pesquisar (Search). A Restauração Instantânea (Instant Restore) monta o ponto de recuperação como um volume para cópia rápida de arquivos. Você pode restaurar para os caminhos originais ou alternativos e até mesmo para outro servidor, usando as credenciais do cofre no destino e autenticando-se no cofre.
• Gerenciamento da passphrase: O agente MARS usa uma passphrase de criptografia (AES-256) mantida pelo cliente, gerada e armazenada localmente; a Microsoft nunca a possui. A perda da passphrase torna a recuperação impossível. Armazene-a em um local seguro e com backup (por exemplo, um segredo do Key Vault com suporte de HSM e selado com RBAC). Para rotacionar, pare a proteção e proteja novamente com uma nova passphrase. Habilite os recursos de exclusão reversível (soft delete) e PIN de segurança no cofre para proteger contra parada/exclusão mal-intencionada.

Azure Backup com MABS/DPM e IaaS

• Backup de Recuperação Bare-Metal (BMR): Use o Microsoft Azure Backup Server (MABS) ou o System Center DPM para capturar o BMR para o Windows Server. Isso permite reconstruções completas do servidor em um novo hardware ou em uma VM, inicializando o WinRE ou a mídia de instalação e apontando para a imagem BMR.
• Recuperação para local alternativo: Para backups de arquivos/dados via MARS/MABS/DPM, restaure para um caminho alternativo ou um servidor diferente para evitar a sobregravação dos dados de origem. Para backups de VMs IaaS do Azure (em um Recovery Services vault), restaure para uma nova VM, restaure discos para uma VM existente ou substitua os discos. Com a Restauração Entre Regiões (Cross-Region Restore) habilitada no cofre, você pode restaurar na região emparelhada para cenários de interrupção regional.
• SQL e SAP HANA em VMs do Azure: Proteja com extensões com reconhecimento de workload (workload-aware) para obter backups consistentes com a aplicação e restauração granular de banco de dados. Alinhe a frequência do backup de log ao RPO (por exemplo, 15 minutos) e a retenção às necessidades de conformidade.

Windows Server Backup (WSB)

• Recuperação bare-metal: O WSB pode capturar BMR (volumes do sistema e Estado do Sistema). Armazene em um disco ou volume dedicado para múltiplos pontos de recuperação. Para destinos de compartilhamento de rede, apenas a versão mais recente é mantida. Recupere inicializando a partir da mídia do Windows no WinRE, selecionando “Recuperação da Imagem do Sistema” (System Image Recovery).
• Backup do Estado do Sistema: Fornece recuperação rápida do AD DS, registro e arquivos de inicialização. Útil para controladores de domínio e servidores de configuração. Combine com backups de arquivos agendados para uma cobertura mais ampla.
• Agendamento: Use o MMC do WSB ou o

undefined

para agendar backups diários/por hora. Escolha VSS Completo (Full) vs Cópia (Copy) dependendo se você deseja truncar os logs da aplicação. Garanta que as janelas de backup evitem o pico de E/S (I/O) e verifique a integridade do catálogo (

undefined

).

Tipos de cofre: Recovery Services vault vs Backup vault

• Recovery Services vault (RSV): O cofre tradicional para backups de VMs do Azure, backups do agente MARS, MABS/DPM, backup do Azure Files, SQL Server em VM do Azure e SAP HANA em VM do Azure. Ele também hospeda metadados do ASR. Ele suporta recursos como exclusão reversível (soft delete), PIN de segurança e Restauração Entre Regiões (Cross-Region Restore) (quando aplicável).
• Backup vault: O cofre modernizado para certas workloads nativas do Azure, como backup do Azure Disks e backup do Azure Blobs, e servidores flexíveis do Azure Database for PostgreSQL. Ele usa o RBAC do Azure para autorização no plano de gerenciamento, suporta chaves gerenciadas pelo cliente (customer-managed keys), opções de imutabilidade e se integra com o Resource Guard para proteção de operações críticas. Ele não hospeda metadados do ASR e, até o momento, não substitui o RSV para backups de MARS/MABS/DPM ou da maioria das VMs IaaS.

HA no nível da aplicação: SQL Always On e DFS Replication

Alguns workloads exigem replicação nativa que complementa ou substitui o DR no nível do hypervisor, dependendo do RTO/RPO.

Always On Availability Groups (AGs)

• Commit síncrono vs. assíncrono: O commit síncrono aguarda o secundário consolidar o log antes de confirmar a transação no primário, proporcionando perda de dados quase nula (RPO baixo) ao custo de latência e throughput; use em links de baixa latência (geralmente na região metropolitana/metro). O commit assíncrono não espera pelo secundário, permitindo maior desempenho em links WAN com potencial perda de dados durante o failover (RPO mais alto).
• Condições de failover automático: O failover automático requer pelo menos duas réplicas de commit síncrono com o failover automático ativado e sincronizadas. O Windows Server Failover Clustering monitora a saúde dos nós/serviços; a política de failover flexível do SQL Server define os níveis de condição de falha (desde falhas de processo até problemas graves de I/O). A detecção de saúde do banco de dados pode ser ativada para forçar o failover quando o banco de dados primário está sob suspeita. O design de quorum e witness garante que o split-brain seja evitado; garanta que os IPs do DNS e do listener estejam prontos no site de recuperação para uma reconexão rápida do cliente.

DFS Replication (DFSR)

• Grupos de replicação e conexões: Um grupo de replicação é um conjunto de servidores que replicam uma ou mais pastas replicadas. As conexões definem a topologia (full mesh, hub-spoke) e o agendamento/limitação de largura de banda. Use a topologia hub-spoke para obter escalabilidade e facilitar a solução de problemas.
• Área de staging: O DFSR usa uma área de staging por pasta replicada para armazenar arquivos delta para o Remote Differential Compression (RDC). Dimensione a área de staging para, no mínimo, o tamanho do seu maior arquivo e, normalmente, de 1 a 2 vezes a rotatividade (churn) diária esperada; um dimensionamento insuficiente causa limpeza e novas tentativas excessivas, prejudicando o RPO/RTO.
• Resolução de conflitos: O DFSR é multi-master. Quando ocorrem edições simultâneas, o DFSR emprega vetores de versão e timestamps; o último a gravar vence (“last-writer wins”) e a cópia perdedora é movida para a pasta ConflictAndDeleted (espaço regido por cota). Para evitar conflitos iniciais durante o seeding, defina um membro como primário apenas para a sincronização inicial. Para cenários unidirecionais, use pastas replicadas somente leitura. Monitore os backlogs com o dfsrdiag e ajuste os agendamentos para atender ao RPO.

Impacto do RTO/RPO e de planos de DR integrados na arquitetura

• RPO agressivo: Favoreça a replicação síncrona de banco de dados ou o ASR com processamento de alterações de alta frequência e snapshots consistentes com o aplicativo. Isole o tráfego de replicação e dimensione os servidores de processo. Use grupos de consistência de várias VMs com moderação, apenas para camadas fortemente acopladas.
• RTO agressivo: Pré-provisione VNets, sub-redes, Route Tables e NSGs de destino; crie scripts para reatribuições de IP e atualizações de DNS por meio de planos de recuperação e runbooks. Mantenha imagens golden e tamanhos de VM fixados em SKUs com capacidade disponível. Teste os failovers trimestralmente e após alterações relevantes.
• Camadas de proteção de dados: Combine o ASR (recuperação rápida de serviços) com o Azure Backup (restauração para um ponto no tempo) para lidar tanto com falhas catastróficas quanto com corrupção lógica. Para controladores de domínio, combine backups do Estado do Sistema (MARS ou WSB) com ASR/failovers de teste para validar a recuperação segura contra reversão de USN. Para serviços de arquivo, o DFSR oferece alta disponibilidade dentro do site e entre sites, com o Azure Backup para recuperação resistente a ransomware.

Cenário de Problema Prático

A Fabrikam, Inc., uma fabricante global, opera um ambiente misto: Hyper-V para as camadas de aplicativos de ERP, VMware para middleware legado, AGs do SQL Server 2019 para bancos de dados e grandes servidores de arquivos Windows usando DFS Replication. O negócio exige RTO ≤ 1 hora e RPO ≤ 15 minutos para o ERP; outras cargas de trabalho podem tolerar RTO de 4 horas e RPO de 24 horas.

1. Classificar cargas de trabalho e metas de RTO/RPO

• VMs de aplicativo/web do ERP e AGs do SQL sinalizados como Tier 1 (RTO 1h, RPO 15m). Middleware e serviços de arquivo são Tier 2/3.
• Por quê: Garante que os objetivos mais rigorosos direcionem as escolhas de replicação e orquestração.

2. Implementar o ASR para as camadas de ERP em Hyper-V

• Instale o ASR Provider nos hosts Hyper-V e registre-os em um cofre dos Serviços de Recuperação. Crie uma política de replicação com um limite de RPO de 15 minutos, snapshots consistentes com o aplicativo a cada hora e retenção de 48 horas. Habilite um grupo de consistência de várias VMs entre os servidores de aplicativos do ERP que compartilham transações com o listener do SQL.
• Por quê: A replicação contínua e os pontos de verificação consistentes com o aplicativo alcançam o RPO de 15 minutos, mantendo a camada consistente.

3. Implementar o ASR para o middleware em VMware

• Implante um servidor de configuração no ambiente local (on-premises), com um servidor de processo colocalizado e dimensionado para a rotatividade (churn) projetada. Adicione um servidor de processo de scale-out no maior site. Instale o Mobility Service nas VMs protegidas. Prepare um servidor de destino mestre para um eventual failback.
• Por quê: A arquitetura do ASR para VMware fornece captura de alterações confiável e um caminho controlado para failback quando o site local se recuperar.

4. Orquestrar com planos de recuperação e runbooks

• Crie um plano de recuperação agrupando o SQL (dados), depois as camadas de aplicativo do ERP e, em seguida, as camadas da web. Insira runbooks do Azure Automation para: reconfigurar NSGs, atualizar zonas de DNS privado para apontar para IPs do Azure e alternar os endpoints do Traffic Manager. Adicione uma etapa de validação manual antes de colocar a web online.
• Por quê: A automação comprime o RTO e reduz o erro humano durante uma crise, impondo a ordem de inicialização e o estado de rede corretos.

5. Proteger o SQL Server com AGs ajustados por site

• Mantenha o primário e um secundário em commit síncrono dentro da região metropolitana para um RPO próximo de zero; mantenha um secundário de DR distante em commit assíncrono. Configure o failover automático entre as réplicas síncronas com a detecção de integridade do banco de dados habilitada. Integre as etapas de failover do AG ao plano de recuperação do ASR para visibilidade cruzada.
• Por quê: Os AGs síncronos entregam o RPO mais baixo para a camada de banco de dados; o ASR fornece a orquestração do site em torno dele.

6. Adicionar camadas de backups com o Azure Backup

• Para servidores Windows locais que exigem proteção de arquivos e do Estado do Sistema, implante o agente MARS e configure políticas com backups diários e retenção de 30/52/7 (diária/semanal/anual). Armazene e proteja a senha de criptografia no Azure Key Vault (com backup de HSM). Use o MABS para capturar imagens BMR para servidores de aplicativos críticos para permitir uma reconstrução completa, se necessário. Habilite a exclusão reversível (soft delete) e o PIN de segurança no cofre.
• Por quê: A recuperação para um ponto no tempo protege contra corrupção lógica e ransomware, complementando o failover rápido do ASR.

7. Fortalecer o DFSR e fazer backup dos serviços de arquivo

• Revise a topologia do grupo de replicação (hub-spoke), garanta que as áreas de preparo (staging areas) sejam dimensionadas para 1,5x da rotatividade diária e ajuste os agendamentos para manter a replicação quase em tempo real dentro da região. Proteja os compartilhamentos com MARS/MABS para retenção de longo prazo e testes de recuperação em local alternativo.
• Por quê: O ajuste adequado do DFSR atende à disponibilidade do dia a dia, enquanto os backups fornecem segurança para reversão (roll-back).

8. Validar com failovers de teste e runbooks documentados

• Execute failovers de teste do ASR trimestralmente em uma VNet isolada, valide a funcionalidade do ERP com dados mascarados e meça o RTO. Realize exercícios de restauração: restaurações do MARS em local alternativo e uma recuperação BMR completa do MABS para um ambiente de sandbox.
• Por quê: Exercícios regulares comprovam o plano, revelam desvios (drift) e fornecem evidências executivas de conformidade com o RTO/RPO.

Este design atende aos objetivos da Fabrikam: o ASR entrega um RTO inferior a uma hora, os AGs do SQL em modo síncrono minimizam o RPO para os bancos de dados, e o Azure Backup com MARS/MABS fornece recuperação segura para um ponto no tempo e capacidade de reconstrução completa da máquina. Os planos de recuperação e runbooks removem a ambiguidade durante incidentes, e o DFSR permanece otimizado para a continuidade operacional entre os backups.

← Hyper-V · Todos os domínios · Gerenciamento de Identidade e Acesso para Ambientes Híbridos →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →