Preciso estruturar backup de verdade
Resposta rápida
Backup só vale quando restaura. A pergunta certa não é "fizemos backup?" — é "conseguimos restaurar em quanto tempo, do que e com qual perda aceitável?". Estruture em quatro passos. Primeiro, classifique os dados por criticidade e defina, para cada classe, RPO (quanta perda você aceita) e RTO (em quanto tempo precisa estar de volta). Segundo, aplique a regra 3-2-1: três cópias, em dois meios diferentes, com uma fora do ambiente principal e idealmente imutável contra ransomware. Terceiro, automatize coleta e monitoramento, com alerta em falha. Quarto — o mais ignorado — teste a restauração trimestralmente, com cenário real, e documente o tempo. Backup que nunca foi restaurado é declaração de fé, não plano.
Na empresa pequena, backup costuma ser operado pelo MSP ou pelo ponto focal interno, com solução SaaS gerenciada (Veeam Backup for Microsoft 365, Acronis, Datto, alternativa nacional). O essencial é cobrir três frentes: dados de produtividade (e-mail, drive, documentos), dados de sistemas críticos (ERP, gestão financeira, base de cliente) e configuração de equipamentos críticos. Aplique 3-2-1 com cópia em cloud e responsável claro pelo monitoramento diário. Teste restauração ao menos trimestralmente — mesmo que seja restaurar um arquivo aleatório, um e-mail, uma máquina virtual de teste. Em pequena, o risco maior é descobrir só em incidente que o backup do SaaS contratado não cobre o que se imaginava.
Na empresa média, backup vira disciplina formal — solução corporativa (Veeam, Commvault, Rubrik, Veritas), com agente em servidor, integração com aplicações críticas e console centralizado de monitoramento. Defina políticas por classe de dado (frequência, retenção, destino), com RPO e RTO claros aprovados pela diretoria. Inclua proteção contra ransomware com cópia imutável (object lock, air gap) e segregação de credenciais administrativas do backup do resto do ambiente. Teste de restauração trimestral com cenário real, registrado em ata. Em média, o risco maior é tratar backup como linha de orçamento e esquecer que ransomware moderno destrói também a cópia online — imutabilidade não é luxo.
Na empresa grande, backup integra plano formal de continuidade e recuperação (DR), com tier por aplicação (crítico, importante, padrão), site secundário ou região cloud alternativa, replicação contínua para sistemas tier 1, snapshots, cópia imutável e isolada, e simulações periódicas de recuperação em escala. Operado por equipe dedicada ou serviço gerenciado especializado, com governança formal, indicadores (RPO real, RTO real, taxa de sucesso, taxa de teste) e revisão em comitê. Cobertura inclui ambientes on-premise, cloud, SaaS e endpoints. O risco maior é o "backup que funciona em condição feliz": testes precisam incluir cenários ruins (sítio principal indisponível, credenciais comprometidas, dados corrompidos).
- Tem backup configurado, mas ninguém testou restauração no último ano
- Não há classificação clara de qual dado é mais crítico que qual
- O backup do Microsoft 365 ou Google Workspace é "o que vem nativo"
- O monitoramento avisa por e-mail genérico que ninguém lê
- Cópia única, no mesmo ambiente, sem cópia fora ou imutável
- Responsável pelo backup mudou de função e ninguém assumiu formalmente
RPO e RTO traduzem expectativa em projeto
Os dois indicadores que orientam qualquer estratégia de backup são RPO (Recovery Point Objective — quanta perda de dado a empresa aceita) e RTO (Recovery Time Objective — em quanto tempo o serviço precisa estar de volta). Eles precisam ser definidos por classe de dado, com a diretoria, antes de qualquer escolha técnica. ERP que para a operação pode exigir RPO de minutos e RTO de uma hora; arquivo de RH pode aceitar RPO de um dia e RTO de uma semana. Sem essa pactuação, a TI define no escuro e descobre tarde que o que parecia bom era insuficiente.
A regra 3-2-1 e por que ela continua válida
A regra 3-2-1 é a fundação prática do backup: três cópias dos dados, em dois meios diferentes, com uma cópia fora do ambiente principal. Em era de ransomware, vale acrescentar dois reforços: pelo menos uma cópia imutável (object lock, air gap), que não pode ser apagada nem alterada por ninguém — incluindo administrador comprometido —, e credenciais do backup segregadas do resto do ambiente, idealmente em domínio separado. Sem imutabilidade, um ransomware sério criptografa também a cópia online; sem segregação de credenciais, atacante com acesso administrativo apaga backup junto com produção.
O que precisa entrar no escopo
Escopo de backup que esquece coisa essencial é a pior surpresa em incidente. Cobertura mínima: bases de dado dos sistemas críticos, e-mail e drive de produtividade (Microsoft 365 e Google Workspace exigem backup à parte, o nativo do provedor não substitui), arquivos compartilhados, configurações de equipamentos críticos (firewall, switch, controladora Wi-Fi), código-fonte e repositórios, e máquinas virtuais ou contêineres que sustentam aplicações. Endpoints (notebooks, estações) costumam ser cobertos via sincronização para drive corporativo, não por backup tradicional. Reveja escopo anualmente — sistemas novos esquecem de entrar.
- Classificação dos dados e definição de RPO/RTO. Com a diretoria, por classe. Sem essa pactuação, técnico decide no escuro.
- Escolha da solução proporcional. SaaS gerenciada em pequena, corporativa em média, plataforma integrada com DR em grande. Inclui suporte e SLA.
- Implantação seguindo 3-2-1 com imutabilidade. Três cópias, dois meios, uma fora, uma imutável. Credenciais segregadas.
- Monitoramento ativo com alerta acionável. Console central, alerta por canal monitorado (não e-mail genérico), responsável claro pela verificação diária.
- Teste de restauração trimestral. Cenário real, tempo medido, ata registrada. Sem teste, backup é fé.
Teste de restauração separa backup real de backup imaginado
O maior risco em backup não é falhar a coleta — é falhar a restauração. Coleta com sucesso aparente, base corrompida, agente desatualizado, credencial expirada, mídia ilegível, processo de recuperação não documentado: todos os modos de falha só aparecem em teste. Faça teste trimestral com cenário concreto: restaurar um banco completo em ambiente isolado, recuperar uma máquina virtual, montar um e-mail antigo. Meça o tempo, valide a integridade, registre em ata. Anualmente, faça exercício maior — simulação parcial de DR com indisponibilidade do ambiente principal. Empresas que descobrem em incidente que o backup não restaura pagam caro.
Não testar restauração. Backup que coleta com sucesso pode estar corrompido, incompleto ou impossível de restaurar a tempo. Sem teste trimestral, não há backup confiável.
Achar que SaaS faz tudo. Microsoft 365 e Google Workspace exigem backup à parte. O nativo do provedor não cobre retenção, granularidade nem ransomware avançado.
Cópia única no mesmo ambiente. Sem cópia fora e sem imutabilidade, ransomware ou incidente físico apaga produção e backup juntos.
Credenciais do backup no mesmo domínio. Administrador comprometido apaga tudo. Segregação de credenciais é proteção elementar.
- Classes de dado com RPO e RTO pactuados pela diretoria
- Regra 3-2-1 implementada, com cópia imutável e cópia fora
- Backup específico para SaaS (Microsoft 365, Google Workspace) contratado
- Credenciais administrativas do backup segregadas do resto
- Monitoramento ativo com alerta em canal acompanhado
- Teste de restauração trimestral com ata e tempo medido
- Responsável formal pelo backup nomeado, com substituto