Projete backup e recuperação com Backup do Azure, armazenamento, SQL e Site Recovery
Converta objetivos de recuperação do negócio em proteção em camadas para blobs, compartilhamentos de arquivos, máquinas virtuais, bancos de dados e cargas de trabalho completas.
Tempo de estudo sugerido: 78 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. O arquiteto converte o risco de interrupção em um design de recuperação
Backup e recuperação de desastre impedem que falha de hardware, erro humano, ação mal-intencionada ou indisponibilidade regional se tornem uma interrupção irrecuperável. A migração para a nuvem não elimina essa responsabilidade: é preciso decidir o que proteger, onde manter as cópias e como restabelecer o serviço dentro dos objetivos.
Considere uma varejista que está migrando sites, dados operacionais e vídeos de datacenters próprios. O reduz atrasos de aquisição, mas cada carga ainda exige uma estratégia adequada. Este capítulo desenvolve essa decisão para ,,,, e .
Projetar requisitos de backup e recuperação.
Selecionar o e proteger seus cofres.
Proteger blobs, arquivos, máquinas virtuais e dados SQL.
Usar o para recuperação orquestrada.
Relacionar as escolhas ao objetivo de continuidade de negócios da AZ-305.
Como pré-requisitos, é recomendável compreender conceitualmente continuidade de negócios e recuperação de desastre (BCDR), conhecer replicação de objetos e ferramentas de recuperação e saber interpretar requisitos de recuperação.
Resumo do tópico
Um bom design liga o impacto comercial a uma cópia recuperável, um caminho de restauração testado e um processo operacional responsável.
2. Confiabilidade e resiliência são propriedades da carga de trabalho
Uma aplicação confiável permanece disponível e íntegra sem tempo de inatividade significativo. Resiliência é a capacidade de absorver uma falha, continuar de forma controlada e retornar a um estado conhecido. Mais servidores ou armazenamento aumentam a redundância, mas a recuperabilidade também depende de dados protegidos e procedimentos praticados.
Defina os requisitos e um plano de resiliência antes de escolher o serviço. Cargas críticas e não críticas raramente justificam a mesma arquitetura, retenção, abrangência regional ou custo.
Resumo do tópico
Confiabilidade é o resultado mensurado de redundância, recuperação, operação e testes, e não apenas o nome de um produto.
3. Separe cargas de trabalho e entenda os padrões de uso
Trate cada capacidade lógica do negócio como uma carga. Mesmo aplicações na mesma plataforma podem ter requisitos diferentes de disponibilidade, escalabilidade, consistência e desastre. Mapeie dependências para não declarar o front-end recuperado enquanto identidade, banco de dados, ou rede continuam indisponíveis.
O padrão de uso estabelece criticidade e geografia. Um serviço de receita pode exigir redundância entre regiões; uma ferramenta interna de baixo impacto pode permanecer em uma região para reduzir custos.
Resumo do tópico
Divida o ambiente por carga e dependência e aplique proteção proporcional ao uso e ao impacto reais.
4. MTBF e MTTR revelam o ritmo esperado de falhas
O tempo médio entre falhas (MTBF) estima quanto um componente opera antes de uma nova falha. O tempo médio de recuperação (MTTR) mede quanto se leva, em média, para restaurá-lo. Juntos, orientam redundância, automação, capacidade de reserva e cobertura de suporte.
Se o MTTR de uma dependência crítica superar o RTO da solução, a promessa não poderá ser cumprida. Remova o gargalo, adicione um caminho mais rápido ou renegocie o objetivo.
Resumo do tópico
Use o MTBF para estimar a frequência de falhas e o MTTR para provar que cada dependência se recupera a tempo.
5. RTO, RPO e RLO formam o contrato de recuperação
Métricas fundamentais de recuperação.
Métrica
Pergunta respondida
Efeito no design
RTO — objetivo de tempo de recuperação
Quanto tempo a carga pode ficar indisponível?
Limita detecção, decisão, restauração, inicialização, validação e troca de tráfego.
RPO — objetivo de ponto de recuperação
Quanto dado recente pode ser perdido?
Limita frequência de backup, atraso de replicação e seleção do ponto.
RLO — objetivo de nível de recuperação
Em que granularidade deve ser possível recuperar?
Define se a unidade é item, banco, aplicação, site ou farm completo.
Avalie o custo e o risco do tempo de inatividade e da perda de dados. Uma restauração rápida do site inteiro não atende à recuperação de um arquivo apagado; a recuperação por item não reconstrói uma região perdida.
As métricas descrevem frequência de falha, velocidade de restauração, perda aceitável e granularidade.
Resumo do tópico
O RTO limita a interrupção, o RPO limita a perda de dados e o RLO define a unidade recuperável.
6. A meta de disponibilidade deve incluir as dependências
Defina um -alvo para cada carga considerando custo, complexidade, dependências e replicação. Um do descreve o compromisso da Microsoft para um serviço; ele é uma entrada do cálculo e não a garantia fim a fim da aplicação.
Uma carga com meta de 99,99% não pode depender de um único componente projetado para 99,9%. Melhore a dependência, crie um caminho alternativo ou aceite uma meta menor.
Resumo do tópico
Calcule a disponibilidade da cadeia completa e não confunda o de um serviço com o da carga.
7. Escolha a tecnologia somente depois de mensurar os objetivos
Com carga, escopo de falha, RTO, RPO, RLO, retenção, conformidade e orçamento definidos, selecione a proteção. Snapshots locais priorizam velocidade; backups em cofre melhoram isolamento; replicação contínua reduz a lacuna de dados; e planos de recuperação orquestram aplicações multicamadas.
Nenhum recurso cobre todos os riscos. Combine controles para que exclusão, corrupção, comprometimento da conta, perda de infraestrutura e indisponibilidade regional não compartilhem o mesmo limite de falha.
Resumo do tópico
Associe cada cenário de falha a um controle cujas características testadas atendam aos objetivos.
8. O protege fontes na nuvem e locais
Opções representativas do .
Fonte
Abordagem
Arquivos, pastas e estado do sistema locais
Agente dos Serviços de Recuperação do (MARS).
Hyper-V, VMware e aplicações locais
System Center Data Protection Manager (DPM) ou Servidor de Backup do (MABS).
Windows e Linux
Backup integral por extensão ou arquivos, pastas e estado do sistema com MARS.
Backup nativo do compartilhamento.
SQL Server ou SAP HANA em VMs do
Backup de banco de dados com reconhecimento da carga.
O substitui mídia física e operações externas por um serviço gerenciado, escalável e baseado em consumo. A origem e o tipo de restauração determinam o componente e o cofre.
O componente e o tipo de cofre variam conforme a carga protegida.
Resumo do tópico
Selecione o componente do a partir da fonte, do local de execução e do escopo de restauração.
9. Cofre de Backup e cofre dos Serviços de Recuperação atendem a cargas diferentes
Um cofre armazena configuração, pontos de recuperação e políticas. O cofre de Backup atende cenários mais recentes do . O cofre dos Serviços de Recuperação atende cargas como VMs e e também armazena a configuração do .
Confirme sempre a matriz de suporte; os recursos não são intercambiáveis apenas porque ambos são “cofres”. Separar Backup e Site Recovery também pode esclarecer permissões, ciclo de vida e responsabilidade.
Resumo do tópico
Escolha o cofre pela carga compatível e pelo limite operacional, nunca somente pelo nome.
10. Organize cofres, políticas e permissões de forma deliberada
Um cofre único é prático quando equipe, assinatura, região, segurança e ciclo de vida coincidem. Use vários cofres quando assinaturas, regiões, administradores, conformidade ou responsabilidades de backup e desastre forem diferentes.
Aplique cada política ao cofre adequado.
Use o para disseminar requisitos de proteção.
Use o controle de acesso baseado em função do () e privilégio mínimo.
Separe a administração das operações destrutivas ou de recuperação quando necessário.
Resumo do tópico
A topologia de cofres deve refletir os limites de assinatura, região, segurança, conformidade e propriedade.
11. Redundância e resiliência cibernética protegem a cópia
Controles de resiliência do cofre.
Controle
Finalidade
LRS
Mantém cópias em um com redundância local.
ZRS
Distribui cópias entre zonas de disponibilidade da região, quando compatível.
GRS
Replica o backup para uma região secundária emparelhada.
Cofre imutável
Impede excluir pontos antes do vencimento e pode bloquear a imutabilidade.
Autorização de vários usuários e Resource Guard
Exige uma segunda fronteira de autorização para ações críticas.
Resiliência no
Centraliza backup, recuperação de desastre, postura, alertas e proteção entre escopos.
Escolha a redundância antes de iniciar a proteção quando a alteração posterior for restrita. A experiência unificada agora se chama Resiliência no e anteriormente era a Central de Continuidade de Negócios do .
A cópia precisa de resiliência geográfica, controle, imutabilidade e monitoramento.
Resumo do tópico
O backup é confiável quando armazenamento, autorização, imutabilidade e monitoramento resistem ao mesmo incidente da produção.
12. O backup operacional de blobs permanece na conta de origem
O backup operacional de blobs de blocos é contínuo e local: os dados permanecem na conta de armazenamento em vez de serem copiados para um cofre. Não há agenda periódica; as alterações são acompanhadas durante a retenção e podem ser revertidas a um ponto escolhido.
Isso acelera a recuperação de exclusão ou corrupção, mas compartilha o limite de falha da conta. Adicione isolamento quando exclusão da conta, ransomware ou administrador comprometido estiverem no modelo de ameaça.
Resumo do tópico
O backup operacional prioriza recuperação contínua e rápida dentro da conta e deve ser complementado quando o risco exige isolamento.
13. Exclusão reversível e controle de versão preservam blobs
A exclusão reversível retém blob, snapshot ou versão excluída por 1 a 365 dias; o padrão comum é sete dias. A exclusão reversível de contêiner restaura o contêiner e seu conteúdo, mas não protege da exclusão da conta.
O controle de versão mantém versões anteriores após gravações. É útil com vários autores, porém consome armazenamento; use o gerenciamento do ciclo de vida para remover versões obsoletas.
As camadas dentro da conta cobrem eventos distintos de exclusão e modificação.
Resumo do tópico
Combine exclusão reversível de contêiner e blob com versões para recuperar exclusões e substituições granulares.
14. Restauração pontual e bloqueios cobrem erros mais amplos
A restauração pontual de blobs de blocos reverte contêineres ou intervalos de blobs a um estado anterior. Ela usa uma política, depende do acompanhamento de alterações e exige retenção inferior à da exclusão reversível. É útil para desfazer muitas gravações e exclusões ou retornar dados de teste a um estado conhecido.
O bloqueio CanNotDelete permite leitura e alteração, mas impede excluir; ReadOnly também impede mudanças. Bloqueios são preventivos e não representam uma cópia histórica.
Resumo do tópico
Use restauração pontual para reversão ampla e bloqueios para impedir ações de gerenciamento; nenhum substitui backup isolado.
15. Snapshots dos são cópias incrementais pontuais
Um snapshot registra toda a árvore do compartilhamento em um instante, armazenando apenas dados alterados. Pode ser criado no portal do ,, bibliotecas, CLI do ou , ou automaticamente por política.
Snapshots são somente leitura e restauram o compartilhamento ou arquivos individuais. O compartilhamento não pode ser excluído enquanto houver snapshots. Como permanecem junto da origem, são úteis, mas não equivalem sozinhos a backup externo.
Resumo do tópico
Snapshots são visões incrementais, imutáveis e rápidas, com restauração por arquivo, mas compartilham a conta de origem.
16. As camadas de snapshot e cofre trocam velocidade por isolamento
Camadas de backup dos .
Camada
Local dos dados
Uso e limitação
Snapshot
Snapshots na conta; no cofre dos Serviços de Recuperação.
Restauração rápida e retenção diária, semanal, mensal ou anual, mas exposta à perda da conta.
Vault-Standard
Blocos alterados transferidos para um cofre de Backup externo.
Retenção de até 10 anos e proteção contra exclusão da conta, ransomware e administrador mal-intencionado.
O backup em cofre dos está em disponibilidade geral. A Microsoft o recomenda para proteção abrangente; confirme região e limitações antes do uso.
Snapshot otimiza a restauração local; o cofre cria uma cópia isolada.
Resumo do tópico
Use snapshot para velocidade e cofre para retenção e resiliência; combine as camadas quando ambos os objetivos existirem.
17. Recuperação de arquivos exige política, monitoramento e prática
Use restauração instantânea para o compartilhamento inteiro ou arquivos selecionados.
Crie pontos sob demanda antes de mudanças arriscadas.
Use alertas e relatórios para identificar proteção ausente ou com falha.
Habilite versões anteriores por integração Windows/VSS quando adequado.
Classifique compartilhamentos públicos e internos para alinhar retenção e isolamento.
Resumo do tópico
Proteção de arquivos é um processo: agende, monitore, crie pontos pré-alteração e pratique a restauração.
18. Políticas Standard e Enhanced moldam o backup de VMs
Comparação de políticas de VM.
Política
Características
Standard
Normalmente um backup diário e snapshots Standard para restauração instantânea; atende muitos cenários consolidados.
Enhanced
Até um backup a cada quatro horas, snapshots ZRS, maior retenção operacional, Trusted Launch, , Premium SSD v2 e snapshot consistente de vários discos .
Ferramentas recentes oferecem suporte Standard limitado a algumas operações do Trusted Launch, mas Enhanced continua sendo a recomendação ampla para recursos modernos. Confirme a matriz atual.
Resumo do tópico
Use Enhanced quando frequência, resiliência zonal, Trusted Launch, discos recentes ou consistência multidisco excederem o Standard.
19. O backup de VM tem fase de snapshot e fase de transferência
O trabalho cria primeiro um snapshot na camada de armazenamento e depois transfere os dados protegidos para um cofre dos Serviços de Recuperação. O snapshot favorece velocidade; o cofre entrega retenção e isolamento. A restauração pode recriar a VM inteira ou recuperar discos e arquivos.
Os pontos podem ser consistentes com o aplicativo, com o sistema de arquivos ou com a falha. Selecione o maior nível que a carga produza de forma confiável. Os dados são criptografados em repouso com Criptografia do Serviço de e há suporte documentado para VMs com Criptografia de Disco do .
O fluxo separa o snapshot rápido da retenção durável no cofre.
Resumo do tópico
Entenda as duas fases e escolha consistência que permita recuperar a aplicação, não apenas a VM.
20. Agende, monitore, teste e distribua restaurações de VMs
Agende fora do pico e evite sobreposição em VMs dependentes.
Agrupe em uma política somente VMs com mesma agenda, frequência e retenção.
Use backup sob demanda para pontos excepcionais.
Monitore trabalhos e ensaie recuperação de VM, disco e arquivo.
Planeje taxa de restauração; contas GPv2 separadas podem reduzir limitação.
Habilite Restauração Entre Regiões em cofres GRS elegíveis para auditoria, teste ou desastre.
A Restauração Entre Regiões é opcional, tem custo e compatibilidade por carga, e o ponto secundário pode atrasar. Ela também se aplica a backups compatíveis de SQL Server e SAP HANA em VMs.
Resumo do tópico
O design de VM só termina quando frequência, isolamento de trabalhos, capacidade e recuperação regional forem testados.
21. Backups automatizados do formam uma cadeia gerenciada
O e a protegem automaticamente os bancos para restauração pontual. Em geral, há backup completo semanal, diferencial a cada 12–24 horas e de transações a cada 5–10 minutos, conforme atividade e computação.
Na restauração, o escolhe a cadeia necessária. O administrador não agenda os trabalhos, mas continua responsável por retenção, autorização, estratégia regional e validação.
O compõe automaticamente a cadeia do instante escolhido.
Resumo do tópico
O backup gerenciado elimina o agendamento, mas não a responsabilidade por retenção, acesso, escopo e região.
22. O oferece recuperação pontual, de exclusão, geográfica e de longo prazo
A restauração pontual cria um novo banco no mesmo servidor lógico ou instância, com outro nome.
Um banco excluído pode ser recriado no mesmo servidor ou instância em um ponto retido.
A restauração geográfica cria um banco em servidor ou instância disponível em outra região.
A retenção de longo prazo copia backups completos selecionados para redundante por até 10 anos.
A retenção de curto prazo cobre 1–35 dias conforme a configuração. A de longo prazo atende histórico e conformidade e restaura como novo banco. Para RTO ou RPO regional mais rigoroso, combine backup com replicação geográfica ativa ou grupos de .
Resumo do tópico
Escolha a recuperação SQL pelo incidente e valide o novo banco antes de direcionar a produção.
23. O protege cargas em execução entre locais
O replica computadores compatíveis do local primário ao secundário e orquestra e . Há cenários entre regiões do e de VMware, Hyper-V, servidores físicos, Stack e outras origens compatíveis para o .
O portal do centraliza replicação, integridade, testes, planejado ou não e nova proteção. O serviço move dados sem interpretar a aplicação; a VM de destino nasce do armazenamento replicado.
Resumo do tópico
O Site Recovery gerencia replicação e orquestração de VMs; a correção da aplicação ainda requer recuperação e validação conscientes da carga.
24. Replicação contínua reduz o RPO e pontos consistentes melhoram a recuperação
Recursos do Site Recovery.
Recurso
Valor de design
Replicação contínua
Alterações de VMs do e VMware são contínuas; Hyper-V pode chegar a 30 segundos.
Ponto consistente com o aplicativo
Captura disco, memória e transações em andamento com coordenação compatível.
de teste
Ensaia a recuperação sem interromper a replicação.
planejado
Coordena interrupção esperada buscando nenhuma perda quando a origem está disponível.
não planejado
Recupera evento inesperado com perda limitada pelo ponto disponível.
Retorna a carga quando o local primário estiver íntegro.
Meça RTO e RPO da aplicação. Integridade, taxa de alteração, rede, dependências, , troca de tráfego e validação alteram o resultado.
Resumo do tópico
Frequência e consistência reduzem risco, mas só o teste fim a fim comprova os objetivos.
25. Planos de recuperação orquestram o multicamada
Um plano agrupa máquinas e inicia camadas na ordem correta: banco primeiro, depois e front-end por último. Máquinas de um grupo podem recuperar em paralelo; grupos avançam em sequência.
O plano pode incluir runbooks da do , scripts e pausas manuais. O Site Recovery integra rede e pode coordenar tecnologias como SQL Server . Teste sem interrupção e atualize o plano conforme as dependências mudarem.
O plano transforma máquinas replicadas em recuperação ordenada e testável.
Resumo do tópico
Planos reduzem erro manual ao registrar ordem, automação e validação da aplicação inteira.
26. e Site Recovery resolvem problemas complementares
Papéis complementares.
Serviço
Finalidade
Objetivo típico
Reter pontos recuperáveis por curto ou longo prazo.
Restauração granular, corrupção, conformidade e exclusão.
Manter réplica em outro local e orquestrar ativação.
RTO e RPO menores em perda de site ou região.
Use ambos quando forem necessários continuidade rápida e histórico. A replicação pode reproduzir corrupção; o backup preserva pontos anteriores. O backup pode restaurar dados, mas levar mais tempo para reconstruir o serviço completo.
Resumo do tópico
Site Recovery acelera continuidade; preserva histórico. Combine quando os dois riscos importarem.
27. Verificação de conhecimento
Escolha a melhor resposta.
Requisito
Resposta
Replicar uma VM do para outra região com RTO e RPO rigorosos.
.
Proteger uma VM local com backup gerenciado por consumo.
com agente ou servidor adequado.
Manter banco de pool elástico disponível após perda da região primária.
Exclusão reversível de blob, complementada conforme o risco.
A prova avalia o comportamento: cópia retida versus réplica em execução e controle dentro da conta versus isolamento externo.
Resumo do tópico
Associe replicação à retomada rápida, backup a pontos históricos, geo-replicação ao SQL regional e exclusão reversível ao blob apagado.
28. Construa uma arquitetura defensável de backup e recuperação
Inventarie cargas, dados, dependências, proprietários e falhas.
Acorde RTO, RPO, RLO, disponibilidade e retenção.
Escolha cópias locais, zonais, regionais ou externas sem um limite de falha comum.
Defina cofre, redundância, política, identidade, , imutabilidade e Resource Guard.
Combine proteção nativa, , replicação de banco e Site Recovery.
Documente ordem, capacidade, rede, , tráfego e .
Monitore com Resiliência no e alertas.
Teste restaurações e failovers e compare os resultados com os objetivos.
Resumo do tópico
A arquitetura final deve ser rastreável do impacto até a cópia isolada, a orquestração e a evidência dos testes.
29. Síntese do capítulo e próximos passos
Agora você pode separar métricas de produtos, distinguir snapshots locais de cópias isoladas, projetar proteção de blobs, arquivos, VMs e e posicionar o Site Recovery ao lado do . Isso atende diretamente ao objetivo AZ-305 de recomendar recuperação para ambientes e híbridos.
Pratique com uma carga real: desenhe dependências, atribua RTO, RPO e RLO e ensaie uma restauração por item e uma recuperação regional. Registre tempo, ponto dos dados, etapas manuais e dependências inesperadas.
No Microsoft Edge, use o Microsoft Learn com o Copilot para comparar serviços de backup e recuperação de VMs e explicar quando cada opção se aplica.
Peça ao Copilot para contrastar as opções de backup e recuperação do e confira cada recomendação na documentação vinculada.
Como laboratório, proteja uma VM de teste com o e execute uma restauração sem afetar recursos de produção.
Resumo do tópico
O domínio é comprovado quando a carga completa, e não somente um recurso configurado, volta dentro dos objetivos.
