Configurar o Azure Site Recovery permite replicar servidores e máquinas virtuais para outra região ou para o Azure, criando uma infraestrutura pronta para assumir operações automaticamente em caso de falha. Na prática, isso significa manter aplicações críticas funcionando mesmo quando o datacenter principal sofre interrupções.

Leia mais sobre: Azure Site Recovery: guia completo de disaster recovery no Azure

Por que empresas implementam Azure Site Recovery

Quando conversamos com gestores de TI sobre recuperação de desastres, a maioria já passou por pelo menos um destes cenários:

  • queda inesperada de storage

  • ransomware que bloqueou servidores

  • manutenção emergencial em infraestrutura

  • indisponibilidade de datacenter

Nessas situações, restaurar apenas um backup não resolve o problema com rapidez suficiente.

É aí que entra o Azure Site Recovery, que mantém uma cópia replicada dos workloads rodando em standby, pronta para assumir o ambiente em minutos.

Na prática, ele protege ambientes como:

  • máquinas virtuais

  • SQL Server

  • servidores físicos

  • infraestrutura VMware

  • Hyper-V

O objetivo não é apenas restaurar dados, mas manter o negócio funcionando mesmo durante uma falha crítica.

Como configurar Azure Site Recovery passo a passo

Agora vamos ao processo real de configuração do Azure Site Recovery.

Esse é o fluxo usado na maioria dos projetos corporativos.

Passo 1 — Criar o Recovery Services Vault

Toda a arquitetura de recuperação de desastres no Azure começa com o Recovery Services Vault.

Ele funciona como o ponto central onde ficam armazenadas:

  • políticas de replicação

  • configurações de recuperação

  • estado das máquinas replicadas

Boas práticas que fazem diferença

Um erro comum em projetos iniciais é escolher a mesma região da infraestrutura principal.

O ideal é sempre usar replicação geográfica.

Exemplo real usado em projetos no Brasil:

Ambiente Região
Produção Brazil South
Recuperação East US

Isso protege o ambiente contra falhas regionais.

Passo 2 — Definir o cenário de replicação

Depois de criar o vault, o Azure pede que você defina de onde e para onde os sistemas serão replicados.

Os cenários mais comuns são:

Azure para Azure

Proteção de máquinas virtuais Azure entre regiões.

Esse é o cenário mais simples.

VMware para Azure

Muito comum em empresas que ainda possuem datacenter próprio, mas querem usar Azure como site de disaster recovery.

Hyper-V para Azure

Usado principalmente em ambientes Microsoft tradicionais.

Servidores físicos

Ainda existe em muitos ambientes corporativos.

Nesses casos, o Azure utiliza agentes para replicar o servidor diretamente para a nuvem.

Passo 3 — Configurar a replication policy

Aqui definimos como o Azure vai replicar os dados.

Alguns parâmetros são críticos.

Frequência de replicação

Em ambientes críticos, usamos 30 segundos.

Isso significa que a perda máxima de dados em um desastre será inferior a meio minuto.

Retenção de recovery points

Normalmente configuramos:

24 horas de histórico.

Isso permite restaurar estados anteriores do sistema.

Consistência de aplicações

Para workloads como SQL Server, habilitar application-consistent snapshots é essencial.

Caso contrário, bancos de dados podem subir com inconsistências.

Passo 4 — Iniciar replicação das máquinas

Depois da política definida, iniciamos a replicação de workloads.

Nesse momento o Azure começa a copiar:

  • discos

  • sistema operacional

  • configuração da máquina

Dependendo do tamanho da VM, a primeira sincronização pode levar horas.

Depois disso, apenas as mudanças são replicadas.

Passo 5 — Criar Recovery Plans

Esse é o recurso que realmente diferencia o Azure Site Recovery.

Um Recovery Plan define a ordem de recuperação dos sistemas.

Por exemplo:

1️⃣ subir SQL Server
2️⃣ subir servidores de aplicação
3️⃣ subir servidores web

Sem isso, aplicações complexas podem falhar na inicialização.

Também é possível incluir:

  • scripts de automação

  • runbooks

  • integrações com DevOps

Passo 6 — Testar failover sem parar produção

Um recurso extremamente útil do Azure é o test failover.

Ele permite simular um desastre sem afetar o ambiente produtivo.

Na prática, o Azure cria:

  • máquinas replicadas

  • rede isolada

  • ambiente de teste

Isso permite validar:

  • conectividade

  • funcionamento da aplicação

  • dependências de rede

Empresas maduras realizam esse teste ao menos duas vezes por ano.

Passo 7 — Executar failover real

Quando ocorre um incidente real, o failover pode ser executado diretamente no portal Azure.

O processo ativa automaticamente as máquinas replicadas.

Em poucos minutos:

  • servidores voltam a operar

  • aplicações ficam disponíveis

  • usuários continuam trabalhando

Caso real de uso

Um exemplo interessante vem da ASOS, empresa global de e-commerce.

Eles utilizam Azure para manter infraestrutura resiliente e garantir que falhas de sistema não derrubem sua operação online.

Resultado:

  • maior estabilidade da plataforma

  • recuperação rápida após incidentes

  • replicação entre regiões Azure

Fonte: https://azure.microsoft.com/customers/asos/

FAQ – Perguntas frequentes sobre Azure Site Recovery

Como configurar Azure Site Recovery?

O processo envolve:

  1. criar Recovery Services Vault

  2. configurar replication policy

  3. replicar máquinas virtuais

  4. criar Recovery Plans

  5. executar test failover

Azure Site Recovery funciona com VMware?

Sim. Ele permite replicar ambientes VMware diretamente para Azure, transformando a nuvem em um site de disaster recovery.

Qual a diferença entre Azure Backup e Azure Site Recovery?

Azure Backup

  • restaura dados

Azure Site Recovery

  • mantém infraestrutura pronta para assumir produção

Como testar failover no Azure?

Utilize a opção Test Failover no portal Azure. O serviço cria um ambiente isolado para validação.

Azure Site Recovery protege servidores físicos?

Sim. É possível replicar servidores físicos diretamente para Azure.

Azure Site Recovery funciona entre regiões?

Sim. A solução suporta replicação geográfica entre regiões Azure.

Conclusão

A diferença entre ter backup e ter disaster recovery só aparece quando algo dá errado.

Empresas que implementam Azure Site Recovery conseguem manter sistemas críticos operando mesmo durante falhas graves de infraestrutura.

Em vez de esperar horas ou dias por restauração de backups, o ambiente simplesmente assume automaticamente em outra região.

Isso reduz drasticamente o impacto operacional de incidentes.

Proteja sua infraestrutura com especialistas Azure

Projetar uma estratégia real de recuperação de desastres exige análise da arquitetura, definição de RTO/RPO e testes regulares.

A Infob ajuda empresas a implementar Azure Site Recovery de forma segura, garantindo:

  • replicação de workloads críticos

  • automação de failover

  • continuidade operacional

Agende uma conversa com um especialista da Infob e descubra como proteger sua infraestrutura antes que um incidente aconteça.