Toda empresa tem um plano de backup. Pelo menos no papel. Mas quando o ransomware criptografa o file server às duas da manhã de um sábado, ou quando a região de nuvem que hospeda seu ERP fica indisponível por horas, o que aparece não é o slide bonito da última reunião de diretoria. O que aparece é pânico, improviso e prejuízo.

Montar uma estratégia séria de backup e disaster recovery na Azure não é só contratar um serviço e esquecer. É entender o que precisa ser protegido, quanto tempo de parada o negócio aguenta e até onde o orçamento permite ir. Este artigo traz essa conversa de forma direta, com o que realmente importa para quem toma decisão em TI.

Antes de tudo: RTO, RPO e a regra que ninguém deveria ignorar

RTO e RPO sem enrolação

RTO (Recovery Time Objective) é o tempo máximo que seu ambiente pode ficar fora do ar até a operação voltar. Se o seu RTO é de quatro horas, qualquer coisa acima disso já causa impacto financeiro mensurável, reclamação de cliente e, em alguns setores, problema regulatório.

RPO (Recovery Point Objective) é a quantidade de dados que você aceita perder. Um RPO de uma hora significa que, no pior cenário, você perde até sessenta minutos de transações, registros ou atualizações. Para um sistema de e-commerce com milhares de pedidos por hora, isso pode ser inaceitável. Para um servidor de arquivos de documentação interna, talvez seja tolerável.

A definição de RTO e RPO na Azure (ou em qualquer nuvem) deveria partir do negócio, não da TI. Mas na prática, o que acontece muito é o time de infra definir sozinho e o CFO só descobrir quando a fatura chega. Ou pior: quando o desastre chega.

A regra 3-2-1 ainda vale (e muito)

Três cópias dos dados, em dois tipos de mídia diferentes, com pelo menos uma cópia fora do site principal. Essa regra tem décadas, mas continua sendo referência porque ataca o problema certo: eliminar pontos únicos de falha.

Na Azure, aplicar a regra 3-2-1 fica mais simples do que parece. Você pode manter snapshots locais, backup em um Recovery Services Vault numa região diferente e, se quiser, uma cópia adicional em storage com acesso restrito. O ponto é: não confie numa única região, numa única conta ou num único mecanismo.

O que o Azure Backup protege (e o que as pessoas não sabem que ele protege)

Quando alguém fala em Azure Backup, a maioria pensa em backup de VMs. Faz sentido, é o caso de uso mais visível. Mas o serviço cobre bem mais do que isso.

• VMs na Azure (Windows e Linux), com backup consistente por aplicação
• Azure Files (file shares na nuvem), com snapshots integrados
• SQL Server em VMs Azure e Azure SQL Database
• SAP HANA em VMs Azure, com suporte certificado pela SAP
• Servidores on-premise via agente MARS (Microsoft Azure Recovery Services), incluindo Windows Server e clientes Windows
• Azure Managed Disks
• Azure Database for PostgreSQL

Essa cobertura é relevante para empresas que ainda operam em modelo híbrido, o que no Brasil é a maioria. O agente MARS permite que máquinas físicas no datacenter local enviem backups direto para a Azure, sem precisar de uma solução de terceiros intermediando.

Um detalhe que pouca gente aproveita: a retenção de longo prazo. O Azure Backup permite configurar políticas de retenção por anos, com pontos de recuperação diários, semanais, mensais e anuais. Isso resolve uma dor antiga de compliance: manter cópias de segurança por prazos exigidos por auditorias ou regulamentações sem precisar gerenciar fitas LTO num depósito climatizado.

Imutabilidade e soft delete: a linha de defesa contra ransomware

Aqui está algo que merece atenção especial. Os ataques de ransomware modernos não criptografam só os dados de produção. Eles buscam e destroem os backups também. Um backup que pode ser apagado pelo mesmo usuário comprometido não é proteção, é teatro.

O Azure Backup oferece dois recursos para lidar com isso:

• Soft delete: quando alguém apaga um item de backup (seja por acidente ou por ação maliciosa), os dados ficam retidos por 14 dias adicionais, sem custo extra. Dá tempo de perceber e recuperar.
• Immutable Vaults: uma vez configurada a imutabilidade, os pontos de recuperação não podem ser apagados antes do período de retenção definido. Nem o administrador do vault consegue. Isso é particularmente útil quando uma conta privilegiada é comprometida.

A combinação de soft delete com immutable vault cria uma barreira real. Não é infalível (nada é), mas eleva muito o custo de ataque para o adversário. E num cenário de ransomware, cada barreira adicional conta.

Azure Site Recovery: disaster recovery de verdade, com failover testável

Backup e disaster recovery são coisas diferentes, embora muita gente trate como sinônimos. Backup é sobre recuperar dados. Disaster recovery (DR) é sobre manter a operação rodando quando a infraestrutura principal falha.

O Azure Site Recovery (ASR) faz replicação contínua de VMs e permite failover automatizado. Dois cenários principais:

• Azure-to-Azure: VMs numa região (por exemplo, Brazil South) replicam para outra região (East US, por exemplo). Se Brazil South sai do ar, as VMs sobem na região secundária.
• On-premise-to-Azure: máquinas virtuais no datacenter local (Hyper-V ou VMware) replicam para a Azure. Em caso de incidente no site físico, o ambiente sobe na nuvem.

O RPO típico do ASR fica em torno de 30 segundos a poucos minutos, dependendo da carga de replicação. O RTO depende da quantidade de VMs e da complexidade dos planos de recuperação, mas com automação bem configurada, é possível manter na faixa de minutos.

Testes de DR sem parar a produção

Uma das coisas mais inteligentes do ASR é a possibilidade de fazer drills não disruptivos. Você executa um failover de teste numa rede isolada e valida se as VMs sobem corretamente, se as aplicações respondem e se a ordem de inicialização está certa. Tudo isso sem afetar a produção e sem interromper a replicação.

Parece óbvio, mas a quantidade de empresas que tem um plano de DR e nunca testou é assustadora. Já vi planos de recuperação com três anos de idade que referenciavam servidores que nem existiam mais. O ASR remove a desculpa de “testar DR é caro e arriscado”.

Se a sua empresa utiliza Azure e ainda não tem uma estratégia de DR formalizada, a Omega Brasil oferece consultoria em backup e disaster recovery na Azure com foco em definir RTO e RPO realistas para o seu negócio, não valores genéricos copiados de um template.

Três casos de uso que justificam o investimento

Proteção contra ransomware

Já falamos dos immutable vaults, mas o cenário completo é mais amplo. Uma estratégia de recuperação de desastre na nuvem contra ransomware combina: backup imutável com retenção adequada, ASR para failover rápido caso o ambiente principal fique comprometido e políticas de acesso com MFA obrigatória para qualquer operação destrutiva nos vaults.

Sem isso, o que sobra é pagar o resgate ou reconstruir tudo do zero. As duas opções custam mais do que a prevenção.

Conformidade com a LGPD

A Lei 13.709/2018 (LGPD) exige que controladores de dados pessoais adotem medidas técnicas para proteger essas informações contra acessos não autorizados, destruição e perda. Um backup bem configurado com retenção adequada e controle de acesso demonstra diligência técnica, algo que a ANPD pode solicitar em caso de incidente.

Além disso, a possibilidade de restaurar dados específicos (por exemplo, para atender a uma solicitação de portabilidade ou exclusão) é mais fácil quando os backups são granulares e organizados, em vez de imagens brutas de VM sem indexação nenhuma.

Continuidade em caso de queda de região

A região Brazil South da Azure, em São Paulo, concentra a maioria das cargas de trabalho de clientes brasileiros. Quando (não se, quando) houver uma indisponibilidade relevante, quem tiver replicação ASR para outra região vai continuar operando. Quem não tiver, vai ficar olhando o dashboard de status da Microsoft e atualizando a página do Twitter esperando novidades.

Manter uma réplica ativa em outra região não é barato, mas o custo de parada para muitas empresas é maior. Essa conta precisa ser feita com números reais, não com achismo.

Azure Backup vs. soluções de terceiros: Veeam, Commvault e o dilema da escolha

Essa é uma pergunta que aparece em quase todo projeto. Vale usar só o Azure Backup e o ASR, ou é melhor trazer uma solução como Veeam Backup for Microsoft Azure ou Commvault?

A resposta honesta é: depende.

O Azure Backup tem a vantagem de ser nativo. Não precisa de agente adicional para VMs Azure, a integração com Azure Policy é direta e o billing vem consolidado na mesma fatura. Para ambientes 100% Azure, ele resolve a maioria dos cenários sem adicionar complexidade.

Veeam e Commvault entram com vantagem quando o ambiente é multi-cloud (Azure + AWS + GCP) ou fortemente híbrido, com muita carga on-premise. Eles oferecem console unificada, orquestração de DR mais sofisticada e, em alguns casos, compressão e deduplicação mais agressivas, o que pode reduzir custos de storage.

O trade-off: mais uma licença para gerenciar, mais um fornecedor para negociar renovação e mais uma ferramenta que o time precisa conhecer. Em empresas com equipe de infra enxuta (e no Brasil, a maioria das equipes é enxuta), isso pesa.

Critério	Azure Backup / ASR	Veeam / Commvault
Integração nativa com Azure	Total	Via agente/plugin
Multi-cloud	Não	Sim
Custo de licença adicional	Incluso no consumo Azure	Licença separada
Complexidade operacional	Menor	Maior (mais opções, mais controle)
Deduplicação avançada	Limitada	Mais eficiente em alguns cenários
Console unificada multi-ambiente	Só Azure	Sim
Suporte a ambientes on-premise complexos	Via MARS/ASR	Mais maduro

Para a maioria das empresas brasileiras de médio porte com foco em Azure, a combinação nativa é suficiente e mais simples de manter. Para ambientes enterprise com múltiplas nuvens e datacenters, vale avaliar Veeam ou Commvault. Não existe resposta universal aqui.

A Omega Brasil, como integradora de TI corporativa e parceira Microsoft, ajuda a avaliar se a solução nativa atende ou se faz sentido combinar com ferramentas de terceiros, sempre olhando para custo total e capacidade operacional do time.

Quanto custa backup e DR na Azure?

Custos de Azure Backup têm dois componentes principais: a instância protegida (um valor fixo por mês por VM, banco de dados ou file share) e o storage consumido pelos pontos de recuperação.

Uma VM com 100 GB de dados usados, por exemplo, custa algo em torno de R$ 50 a R$ 80 por mês para backup (valores aproximados com base nos preços públicos da Microsoft para a região Brazil South, sujeitos a variação cambial e tipo de redundância escolhido, LRS ou GRS).

O ASR cobra por instância protegida: cerca de US$ 25 por VM por mês (preço de lista). O storage da réplica é cobrado à parte, ao preço de Managed Disks na região de destino. Para um ambiente com 20 VMs replicadas, estamos falando de algo entre US$ 600 e US$ 1.000 por mês, dependendo do tamanho dos discos.

Parece caro? Compare com o custo de manter um site de DR físico com hardware redundante, links dedicados e pessoas para operar. Ou compare com o custo de um dia inteiro de operação parada. A conta fecha rápido.

Dica prática: use reservas de storage (Azure Storage Reserved Capacity) para reduzir o custo do armazenamento de backup em até 38% para compromissos de um ano. É uma das formas mais simples de otimizar essa linha no orçamento de nuvem.

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

Azure Backup copia e retém dados para restauração posterior. Você perdeu um arquivo, uma VM corrompeu, precisa voltar ao estado de ontem: isso é backup. O foco é proteção de dados com granularidade (arquivos individuais, bancos de dados, VMs inteiras).

Azure Site Recovery replica ambientes inteiros para outra localidade e permite failover quase imediato. O foco é continuidade de negócio: manter sistemas rodando mesmo quando a infraestrutura principal falha.

São complementares, não concorrentes. A maioria dos ambientes bem protegidos usa os dois. Backup para recuperação granular e retenção de longo prazo. ASR para failover rápido em cenário de desastre.

O Azure Backup protege contra ransomware?

Protege, desde que configurado corretamente. Um backup sem imutabilidade pode ser apagado pelo atacante que comprometeu credenciais administrativas. Já um vault com immutable policy habilitada e soft delete ativo cria uma camada que o ransomware não consegue destruir via console ou API.

Mas atenção: backup sozinho não é estratégia anti-ransomware. Ele é a última linha de defesa. Antes dele, precisam existir controles de acesso, segmentação de rede, EDR nos endpoints e conscientização dos usuários. O backup é o paraquedas reserva, não o principal.

Montando uma estratégia que funciona na prática

Depois de tudo isso, o resumo é relativamente simples, mesmo que a execução não seja.

Primeiro: defina RTO e RPO com o negócio, não só com a TI. Cada sistema crítico precisa de números reais, validados com quem sofre quando ele para.

Segundo: aplique a regra 3-2-1 usando os recursos nativos da Azure. Backup local (snapshots), vault em região primária e réplica do vault em região secundária. Para os sistemas mais críticos, ASR com failover automatizado.

Terceiro: habilite imutabilidade e soft delete em todos os vaults. Não tem motivo para não fazer isso. O custo adicional é mínimo e o risco que mitiga é enorme.

Quarto: teste. Pelo menos uma vez por trimestre, execute um drill de DR com o ASR e valide a restauração de backups críticos. Documente os resultados. Quando a auditoria aparecer (e ela vai aparecer), você terá evidências concretas.

Quinto: revise custos a cada seis meses. Políticas de retenção muito longas em dados que ninguém precisa inflam a conta sem nenhum benefício. Nem todo backup precisa ficar armazenado por cinco anos.

A Omega Brasil projeta estratégias de backup e DR na Azure com RTO e RPO adequados ao seu negócio, incluindo configuração de immutable vaults, planos de failover com ASR e otimização de custos de storage. Se o seu plano de continuidade atual é aquele slide de dois anos atrás, talvez seja hora de uma avaliação honesta. Solicite uma avaliação do seu plano de continuidade com quem entende de Azure de verdade.