Disaster Recovery em Cloud Brasileira 2026: 3-2-1-1-0 na Prática

A regra 3-2-1-1-0 explicada

Evolução da clássica 3-2-1, atualizada pra ameaça de ransomware:

3 cópias do dado

1 cópia em produção (servidor ativo) + 2 backups. Razão: se 1 backup falhar na hora de restore, você ainda tem outro. Cópia única é loteria.

2 mídias diferentes

Não tudo no mesmo tipo de storage. Em ambiente cloud moderno: NVMe no servidor de produção + Object Storage S3 + snapshot em VPS de réplica. Padrão antigo "disco + fita" sobrevive em algumas empresas com requisito específico, mas Object Storage substitui fita na maioria.

1 cópia fora do site (off-site)

Pelo menos uma cópia em local geograficamente separado do site primário. Razão: incêndio, enchente, problema elétrico, ataque coordenado num site não atinge o outro. Em cloud, isso é réplica em datacenter diferente ou região diferente.

1 cópia imutável

Pelo menos uma cópia que nem o administrador pode apagar antes do prazo. Em 2026, isso é Object Lock em compliance mode no Object Storage S3-compatible. Razão: ransomware moderno tenta criptografar/apagar backup antes de pedir resgate — se você não tem cópia imutável, paga ou perde.

0 erros validados em teste de restore

O ponto que mais empresa pula. Backup que nunca foi testado é loteria. Mensal/trimestral, escolha um backup aleatório, restaure em ambiente de teste, verifique integridade. Documente o teste — vira evidência de auditoria.

RPO e RTO — definindo expectativa real

RPO (Recovery Point Objective): quanto dado você pode perder em pior caso (medido em tempo).

RTO (Recovery Time Objective): quanto tempo até estar funcionando de novo.

Categorias típicas por criticidade:

Tipo de dado/sistema	RPO	RTO	Custo relativo
Banco transacional crítico (financeiro, ERP em uso)	Minutos	1-4h	Alto
Aplicação SaaS pagante	1h	2-8h	Médio-alto
Site institucional, blog	24h	24-48h	Baixo
Arquivo morto, log antigo	1 semana	1 semana	Muito baixo
Dev/staging/QA	24h	Restore quando precisar	Mínimo

Erro comum: tratar todo dado com mesmo RPO/RTO. Você acaba pagando demais por dado pouco crítico, ou de menos por dado crítico.

Arquitetura DR por nível de exigência

Nível 1: Backup básico (RPO 24h, RTO 1-3 dias)

Atende site institucional, blog, aplicação não-crítica.

• Backup diário automatizado pra Object Storage Audaks com Object Lock
• Retenção configurável (30-90 dias normalmente)
• Teste de restore trimestral
• Custo: faixa R$ 100-300/mês pra empresa pequena

Nível 2: Backup + réplica de banco (RPO 1-4h, RTO 4-12h)

Atende aplicação SaaS, e-commerce, ERP com criticidade média.

• Backup diário + WAL archiving contínuo (PostgreSQL) ou similar (SQL Server, Oracle)
• Réplica streaming do banco em VPS/servidor separado
• Snapshot do servidor de aplicação periódico
• Failover manual coordenado pelo time
• Teste mensal
• Custo: faixa R$ 500-2.000/mês

Nível 3: DR com failover automatizado (RPO minutos, RTO 1-4h)

Atende banco transacional crítico, fintech, plataforma B2B com SLA contratado.

• Réplica síncrona do banco em segunda região/DC
• Ambiente espelho de aplicação em standby
• DNS com TTL baixo pra failover rápido
• Runbook detalhado, time treinado
• Backup contínuo com Object Lock
• Teste de failover trimestral em ambiente controlado
• Custo: faixa R$ 3.000-10.000/mês ou mais

Nível 4: HA real (RPO ~0, RTO segundos)

Atende fintech regulada, plataforma de trading, sistema com SLA 99,99%+.

• Cluster ativo-ativo entre regiões (mais complexo, ainda raro em cloud BR)
• Replicação síncrona com auto-failover
• Load balancer com health check entre regiões
• Custo: alto, sob configuração

O que costuma quebrar quando o DR é acionado de verdade

Empresa que treinou DR descobre dores comuns:

• DNS demora pra propagar — TTL alto faz cliente continuar batendo no servidor caído
• Backup do banco está corrompido — sem teste mensal, ninguém percebeu
• Senha de root do ambiente DR está perdida — só o ex-admin sabia
• Aplicação não conecta no banco da réplica — string de conexão hardcoded, certificado expirado, firewall bloqueando
• Integração externa (banco, fiscal) não foi configurada na réplica — webhook apontando pro IP antigo
• Time não sabe o que fazer — runbook desatualizado ou nunca documentado

Teste regular evita isso. DR sem teste é "espero que funcione".

LGPD e disaster recovery

Plano de continuidade é exigido pela LGPD e pela Resolução BCB 4.893 pra fintech regulada. Pontos importantes:

• Backup e réplica preferencialmente no Brasil pra evitar transferência internacional
• Notificação à ANPD em prazo curto em caso de incidente comprovado
• Documentação formal do plano de DR
• Teste periódico documentado pra evidência de auditoria

Cloud brasileira simplifica todos esses pontos. Detalhe em LGPD 2026 — ANPD multando empresa.

Audaks: componentes pra implementar DR sério

A Audaks Cloud entrega os blocos necessários pra arquitetura DR completa em cloud brasileira:

• Object Storage S3-compatible com Object Lock: backup imutável anti-ransomware, sem cobrança de egress no restore
• VPS ou servidor dedicado em datacenter Tier III SP pra produção
• Réplica em região/DC separado sob configuração pra cenários de DR avançado
• Backup automatizado compatível com Veeam, Acronis, Restic, WAL-G, pgBackRest
• NF brasileira em Real, contrato com cláusula DPA, suporte 24h em português
• Suporte engineer pra DR design: ajudamos a arquitetar o nível certo de DR pro seu negócio

Leia também: Backup Corporativo — Como Avaliar e Contratar Provedor, Backup Corporativo SLA — guia técnico.

Perguntas frequentes

Backup automatizado é considerado DR?

É a base. DR vai além: inclui plano de failover, ambiente de réplica, runbook, teste periódico, RPO/RTO definidos por categoria. Sem isso, você tem backup, não DR.

Quanto custa implementar DR?

Faixa muito ampla conforme nível exigido. Nível 1 (backup imutável + Object Lock): R$ 100-300/mês. Nível 4 (HA real ativo-ativo): faixa de milhares de Reais/mês. O segredo é dimensionar pelo nível certo pra cada categoria de dado.

Audaks faz teste de DR pelo cliente?

Pra cliente managed, sim. Teste mensal/trimestral documentado, com relatório. Pra cliente self-managed, ajudamos a configurar o ambiente, cliente executa.

Réplica em segunda região reduz latência da aplicação?

Não. Réplica é pra DR, não pra performance. Quem precisa latência baixa em múltiplas regiões usa CDN pra asset estático e múltiplas regiões ativas (muito mais complexo).

Object Lock pode ser quebrado em algum cenário?

Em compliance mode, não — nem root account consegue apagar antes do prazo. Em governance mode, usuário com permissão especial pode (raramente usado, só pra cenário de auditoria que exige correção).