Estratégia de Backup 3-2-1: o “airbag” da empresa contra ransomware, falhas e erros humanos

Tempo de leitura: 8 minutos

Backup não é um “arquivo extra”. Em cibersegurança corporativa, backup é capacidade de continuar operando quando tudo dá errado: ransomware criptografa servidores, um colaborador apaga uma pasta crítica, um notebook some, o provedor tem indisponibilidade, ou um incêndio/enchente atinge o escritório.

A estratégia 3-2-1 é um padrão simples, barato e extremamente eficaz para reduzir o risco de paralisação e perda definitiva de dados — especialmente para empresas pequenas e médias, que costumam ser as mais atingidas por golpes e indisponibilidades.

1) O que é backup 3-2-1

A regra 3-2-1 diz:

  • 3 cópias dos dados (1 original + 2 backups)
  • 2 tipos de mídia/armazenamentos diferentes (ex.: disco local + nuvem; NAS + fita; etc.)
  • 1 cópia fora do ambiente principal (offsite) — para sobreviver a roubo, incêndio, desastre e a certos ataques

Por que isso funciona tão bem?

Porque cobre as três causas mais comuns de desastre digital:

1) Falha técnica (HD/SSD, controladora, RAID que “não era backup”)
2) Erro humano (exclusão, sobrescrita, formatação, configuração errada)
3) Ataque intencional (ransomware, sabotagem interna, invasão de contas)

Frase que dói, mas salva: RAID não é backup; sincronização não é backup. RAID só mantém disponibilidade na falha de um disco. Sync replica o erro humano e o ransomware com eficiência impressionante.

2) O cenário real em 2026: ransomware mira operação, não só dados

Hoje, a chantagem raramente é “pague para descriptografar”. Normalmente é:

  • Criptografar servidores + exfiltrar dados (roubo)
  • Ameaçar vazamento + interrupção prolongada
  • Derrubar backups mal protegidos (apagar snapshots, excluir repositórios, inutilizar credenciais)

Por isso, 3-2-1 moderno costuma virar 3-2-1-1-0 (muito usado no mercado):

  • +1 cópia imutável ou offline (não dá para apagar/alterar facilmente)
  • 0 erros nos testes de restauração (backup sem teste é fé, não controle)

Você pode começar no 3-2-1 e evoluir para o 3-2-1-1-0 sem trocar tudo de uma vez.

3) Antes de comprar qualquer coisa: defina RPO e RTO (o “quanto” e o “quando”)

Dois conceitos guiam o desenho do backup:

  • RPO (Recovery Point Objective): quanto de dado você aceita perder?
    Ex.: “no máximo 4 horas de trabalho”.
  • RTO (Recovery Time Objective): em quanto tempo o sistema precisa voltar?
    Ex.: “o ERP em até 8 horas; e-mail em 24”.

Exemplo prático

Uma clínica:

  • Prontuário/agenda: RPO 1h, RTO 4–8h
  • Documentos administrativos: RPO 24h, RTO 48h

Sem isso, a empresa compra armazenamento “no chute” e descobre a verdade no pior dia possível.

4) Implementando o 3-2-1 na prática (modelos por porte)

🧩 Modelo A — Pequena empresa (até ~30 usuários), baixo custo e alta eficácia

Dados-alvo: arquivos do servidor/NAS, banco do ERP, e-mails, sistemas em nuvem (Microsoft 365/Google Workspace), máquinas críticas.

3 cópias 1) Produção: servidor/NAS + PCs
2) Backup local rápido: NAS dedicado ou appliance de backup (rede local)
3) Backup offsite: nuvem (objeto/backup) ou datacenter

2 mídias diferentes

  • NAS/local (disco) + nuvem (objeto)
    ou disco externo rotativo + nuvem

1 fora do site

  • Nuvem com MFA e conta separada (idealmente com imutabilidade/snapshot)

Rotina recomendada

  • Backup diário incremental + semanal completo (ajuste ao seu RPO)
  • Para bancos de dados: dump/backup consistente (aplicação-aware), não só copiar arquivo “no olho”

🏢 Modelo B — Empresa média, com virtualização e necessidade de retomada rápida

Dados-alvo: VMs (servidores virtuais), bancos, compartilhamentos, AD/IdP, e sistemas críticos.

Arquitetura típica

  • Repositório local (rápido) para restauração em horas
  • Replicação para repositório offsite (nuvem ou site secundário)
  • Cópia imutável (WORM/immutability) por período mínimo (ex.: 14 a 30 dias)

Benefícios

  • Restauração de VM inteira (bare metal/instant recovery)
  • Proteção melhor contra ransomware que tenta apagar backups

5) O que exatamente deve entrar no backup (checklist objetivo)

Muita empresa “faz backup” e esquece o essencial. Em incidentes, os campeões de dor são:

  • ✅ Banco de dados do ERP/CRM (e sua chave/licença)
  • ✅ Arquivos compartilhados (contratos, financeiro, RH)
  • ✅ E-mails e colaboração (M365/Google: caixa postal, OneDrive/Drive, SharePoint)
  • ✅ Configurações de firewall/roteador/switch
  • ✅ Controlador de domínio/identidade (AD/Entra/IdP) e DNS/DHCP quando aplicável
  • ✅ Sistemas de CFTV e controle de acesso (sim — isso também é “segurança”)
  • ✅ Máquinas críticas (PC do financeiro, máquina de emissão de NF, etc.)
  • ✅ Chaves e segredos (certificados, tokens, chaves de API, senhas mestras armazenadas com segurança)

Dica com cara de detalhe, mas não é: backup sem as chaves/certificados pode ser igual a guardar um cofre… sem a combinação.

6) Como evitar que o invasor destrua seus backups (o “pulo do gato”)

Se um atacante obtiver credenciais administrativas, ele tenta:

  • Desativar jobs
  • Excluir repositórios
  • Apagar snapshots
  • Comprometer a conta de nuvem do backup

Controles essenciais

  • MFA obrigatório na nuvem e no console de backup
  • Conta separada para backups (não usar a mesma identidade do ambiente de produção)
  • Privilégio mínimo: quem administra produção não deve, sozinho, administrar também o cofre dos backups
  • Imutabilidade / WORM / Object Lock quando disponível
  • Segmentação de rede: repositório de backup fora do “alcance fácil” das máquinas dos usuários
  • Credenciais guardadas em cofre (password manager corporativo) com controle de acesso

7) Política de retenção (quanto tempo guardar) — sem desperdiçar armazenamento

Uma régua simples (ajuste ao negócio e obrigações legais):

  • Diário: 14 a 30 dias
  • Semanal: 4 a 8 semanas
  • Mensal: 12 meses
  • Anual (opcional): 3 a 7 anos (conforme área/contratos/regulação)

Atenção à LGPD

Backup contém dados pessoais. Isso implica:

  • Controle de acesso
  • Criptografia
  • Registro de auditoria
  • Política de retenção (não é “guardar para sempre” por padrão)

8) Teste de restauração: o passo que separa empresa preparada de empresa “otimista”

Recomendação operacional:

  • Teste mensal: restaurar 1 conjunto pequeno (pasta + alguns e-mails + um banco de teste)
  • Teste trimestral: restaurar um servidor/VM crítica em ambiente isolado
  • Teste semestral/anual: simular desastre (perda do servidor principal) e medir RTO real

Registre os resultados (tempo, falhas, ajustes). Isso vira evidência de governança e melhora contínua.

9) “Estou sob ataque agora”: como usar backup do jeito certo (sem piorar o estrago)

Se houver suspeita de ransomware/invasão:

1) Isole máquinas afetadas (rede/Wi‑Fi) para conter propagação
2) Não conecte HD externo “do backup” em máquina suspeita
3) Preserve evidências (logs, alertas, horários) — útil para investigação e seguro, se houver
4) Verifique se o backup não foi comprometido (jobs apagados, repositório alterado, snapshots sumidos)
5) Restaure primeiro identidade e rede (AD/IdP/DNS, firewall configs), depois sistemas críticos
6) Faça restauração em ambiente limpo (reinstalação/VM nova) para evitar reinfecção

Em incidentes, a pressa costuma fazer a empresa “restaurar” o problema junto com o sistema.

10) Erros comuns que deixam o 3-2-1 bonito no papel e inútil no mundo real

  • Ter backup apenas na mesma rede do ambiente (ransomware agradece)
  • Usar uma única conta com acesso a tudo (produção + backup + nuvem)
  • Não ter inventário do que precisa ser recuperado (dependências esquecidas)
  • Nunca testar restore (“faz tempo que está verdinho, então deve estar ok”)
  • Fazer backup de arquivo de banco “na marra”, sem consistência (backup corrompido)
  • Não proteger endpoints (backup não substitui EDR/antivírus, patching e MFA)

11) Checklist rápido de implementação (para colocar em prática)

  • [ ] Definir RPO/RTO por sistema
  • [ ] Mapear dados críticos e dependências (ERP, e-mail, identidade, financeiro)
  • [ ] Implementar 3-2-1 com offsite real
  • [ ] Habilitar MFA + conta separada + privilégio mínimo
  • [ ] Ativar imutabilidade quando possível
  • [ ] Criar política de retenção (diário/semanal/mensal)
  • [ ] Rodar teste de restauração e registrar tempos
  • [ ] Treinar um “plano de desastre” (quem faz o quê, em que ordem)

Links úteis (Brasil) — referências e orientação técnica

Fechamento (para a mentalidade certa)

A estratégia 3-2-1 não é “paranoia de TI”. É continuidade de negócio: você paga um pouco em organização e disciplina para não pagar muito em resgate, paralisação, retrabalho e dano reputacional. Backup é o único investimento que, quando você precisa, vira superpoder.