Backup e recuperação de desastres no Azure

Backup e DR não são a mesma coisa

Muita gente usa "backup" e "recuperação de desastres" como sinônimos, e essa confusão custa caro na hora de um incidente. Backup é sobre recuperar dados perdidos ou corrompidos — voltar um arquivo, um banco ou um servidor a um ponto anterior no tempo. Recuperação de desastres (DR) é sobre recuperar a operação quando um site inteiro cai — ligar tudo em outra região e continuar trabalhando. Você precisa dos dois, e eles têm ferramentas diferentes no Azure.

Como parceira Microsoft e CSP, a RHC ajuda a desenhar essa proteção com base em duas métricas que definem tudo: RPO e RTO.

RPO e RTO: as métricas que definem o projeto

Antes de escolher tecnologia, defina os objetivos de negócio:

• RPO (Recovery Point Objective) — quanto de dado você pode perder, medido em tempo. Um RPO de 1 hora significa aceitar perder, no pior caso, 1 hora de trabalho.
• RTO (Recovery Time Objective) — quanto tempo você pode ficar parado até restaurar a operação.

Quanto menores o RPO e o RTO, maior o custo da solução. O papel do projeto é casar essas metas com o valor de cada carga — um sistema crítico de faturamento exige RPO/RTO baixíssimos; um servidor de arquivos interno tolera mais.

Azure Backup: proteção de dados

O Azure Backup protege máquinas virtuais, bancos SQL, arquivos e cargas on-premises, guardando os pontos de recuperação em um Recovery Services Vault. Características que importam:

• Retenção configurável — de dias a anos, para atender política e compliance.
• Backup incremental — só as mudanças são enviadas, economizando armazenamento.
• Restauração granular — voltar um arquivo isolado ou a VM inteira.
• Redundância geográfica — cópias em outra região para sobreviver a falhas regionais.

Proteção contra ransomware

O backup virou a última linha de defesa contra ransomware — e os atacantes sabem disso, por isso tentam apagar os backups primeiro. O Azure Backup oferece defesas específicas:

• Soft delete — backups excluídos ficam recuperáveis por um período mesmo após exclusão.
• Imutabilidade — pontos de recuperação que não podem ser alterados ou apagados durante a retenção.
• Autenticação multifator para operações críticas de exclusão.
• Alertas de atividades suspeitas no vault.

Um backup que o atacante consegue apagar não é backup. A imutabilidade é o que garante recuperação após um ataque.

Azure Site Recovery: continuidade de operação

Quando o objetivo é sobreviver à queda de um site inteiro, entra o Azure Site Recovery (ASR). Ele replica continuamente máquinas virtuais para outra região (ou de on-premises para o Azure) e permite um failover orquestrado: com poucos cliques, sua operação sobe na região secundária.

Recursos-chave do ASR:

• Replicação contínua com RPO baixo.
• Planos de recuperação que definem a ordem de subida dos sistemas (banco antes da aplicação, por exemplo).
• Teste de failover sem afetar produção — essencial para validar o DR sem esperar o desastre.
• Failback para voltar à região original depois da normalização.

O erro de nunca testar

O maior risco em DR não é falta de ferramenta — é o plano que nunca foi testado. Um DR que só existe no papel costuma falhar exatamente quando é necessário. Boas práticas:

1. Teste de failover periódico, no mínimo semestral.
2. Documentação viva dos planos de recuperação.
3. Responsáveis definidos para acionar e validar.
4. Revisão após mudanças de arquitetura.

Checklist / Key takeaways

• Backup recupera dados; DR recupera a operação — você precisa dos dois.
• Defina RPO e RTO por carga antes de escolher tecnologia.
• Use Azure Backup para proteção de dados com retenção e imutabilidade.
• Ative soft delete e imutabilidade contra ransomware.
• Use Azure Site Recovery para failover orquestrado entre regiões.
• Teste o failover periodicamente — DR não testado não é DR.

Proteção de dados e continuidade bem desenhadas transformam um desastre potencial em um contratempo controlado. A RHC dimensiona backup e DR ao valor real de cada sistema, equilibrando custo e resiliência.