Continuidade
Checklist de backup 3-2-1: o mínimo para não perder dados
A regra 3-2-1 é citada em todo lugar e cumprida em quase nenhum. Veja o que ela exige de verdade, onde as empresas escorregam e como provar que a restauração funciona antes de um incidente.
Backup não é ter uma cópia. É conseguir voltar a operar depois de um ransomware, um HD queimado ou um arquivo apagado por engano. A regra 3-2-1 existe para garantir que exista pelo menos um caminho de volta quando o principal falhar.
Os três números, traduzidos
- 3 cópias dos dados: a produção + duas cópias de backup. Se uma corromper, ainda sobra uma.
- 2 mídias diferentes: não adianta as duas cópias no mesmo storage. Ex.: disco local + nuvem, ou NAS + fita.
- 1 cópia fora do local (off-site): protege contra incêndio, furto, alagamento e ransomware que se espalha pela rede.
Onde as empresas falham na prática
- As "duas cópias" estão no mesmo servidor — uma pasta chamada
backupno mesmo disco não conta. - O off-site está sempre montado na rede: um ransomware criptografa o backup junto.
- Ninguém testa a restauração. Descobre-se que o job falha há meses só no dia do desastre.
- Retenção curta demais: ataques ficam dormentes por semanas; se você só guarda 7 dias, restaura já infectado.
- Bancos de dados copiados "a quente" sem dump consistente — o arquivo existe, mas não sobe.
- Sem monitoramento: o job falha silenciosamente e o e-mail de alerta vai para a caixa de spam.
3-2-1-1-0: a evolução da regra
A versão moderna acrescenta dois requisitos que o ransomware tornou obrigatórios:
- +1 cópia imutável ou offline: armazenamento que não pode ser alterado nem apagado durante um período (object lock, fita, cofre na nuvem).
- 0 erros na verificação: todo backup é validado e um teste de restauração é feito periodicamente.
Como testar a restauração
- Escolha um conjunto real: um arquivo, uma pasta grande e um sistema inteiro (VM ou banco).
- Restaure em ambiente isolado — nunca por cima da produção.
- Abra os dados: o documento abre? o banco sobe? o sistema loga?
- Meça o tempo. Esse é o seu RTO real (quanto tempo até voltar).
- Confira a data do dado recuperado. A diferença para o momento da falha é o seu RPO real (quanto você perde).
- Registre o resultado e repita pelo menos a cada trimestre.
Frequência e retenção — um ponto de partida
| Dado | Frequência | Retenção sugerida |
|---|---|---|
| Bancos de dados / ERP | A cada 1–4 h | 30 dias + fechamento mensal por 12 meses |
| Arquivos e compartilhamentos | Diária | 30–90 dias |
| Servidores (imagem completa) | Semanal + diferencial diário | 4 semanas |
| Configurações de rede (firewall, switches) | A cada alteração | Últimas 10 versões |
Nota da RELIC
Nas visitas técnicas que fazemos no Grande ABC, o backup quase sempre "existe" — o que falta é a cópia imutável e o teste de restauração documentado. São essas duas peças que separam um susto de uma parada de dias.
Quer uma revisão do seu backup?
A RELIC avalia, corrige e monitora rotinas de backup para empresas de São Bernardo do Campo, do Grande ABC e da Região Metropolitana de São Paulo — incluindo teste de restauração documentado. Veja o escopo completo do serviço de servidores e backup.
Falar com um consultor