A frase "temos backup" aparece em praticamente toda empresa. A pergunta que quase nenhuma consegue responder é outra: quando foi a última vez que alguém restaurou essa cópia em um cenário real de perda de dados? O resultado aparece sempre no pior momento possível, durante um ataque de ransomware, uma falha de disco ou um erro humano que apaga uma base inteira, quando se descobre que a cópia existe, mas não pode ser restaurada no prazo necessário, ou não pode ser restaurada de forma alguma. Nesse instante, a diferença entre uma rotina de backup e um plano de recuperação real deixa de ser um detalhe técnico e passa a determinar se a empresa continua operando ou fica dias, às vezes semanas, sem conseguir atender clientes, faturar ou pagar fornecedores.
Essa diferença entre ter backup e ter um plano de recuperação de desastres é onde mora o risco real para uma empresa brasileira. Backup é uma rotina técnica de cópia de dados. Disaster recovery (DR) é uma capacidade organizacional de voltar a operar depois de um incidente, dentro de um prazo definido e com uma perda de dados aceitável. Este artigo detalha essa diferença, mostra onde as estratégias de backup mais comuns falham silenciosamente e explica como transformar uma rotina de cópia em um plano de recuperação testado e confiável, sem depender de sorte no dia em que o incidente finalmente acontecer.
Backup não é disaster recovery
Ter um backup significa que existe, em algum lugar, uma cópia dos dados da empresa. Isso é necessário, mas está longe de ser suficiente. Um plano de disaster recovery responde a perguntas que o backup sozinho não responde: em quanto tempo a empresa volta a operar depois de um incidente grave (o RTO, ou tempo de recuperação objetivado) e quanto dado a empresa está disposta a perder no processo (o RPO, ou ponto de recuperação objetivado). Sem essas duas definições, ter backup é uma frase que tranquiliza a diretoria sem sustentar nenhuma decisão operacional real. Uma empresa pode ter terabytes de cópias armazenadas e, mesmo assim, não fazer ideia de quanto tempo levaria para colocar o sistema de vendas ou o ERP de volta no ar depois de uma falha grave.
A segunda diferença crítica está na resiliência da própria cópia. Um backup armazenado na mesma rede, nos mesmos servidores ou com as mesmas credenciais de acesso do ambiente de produção está exposto ao mesmo ataque que comprometeu os dados originais. Ataques de ransomware modernos são desenhados precisamente para isso: buscar e criptografar ou apagar backups antes de criptografar os dados principais, para eliminar a via de escape da vítima e forçar o pagamento do resgate. Um plano de disaster recovery maduro pressupõe cópias isoladas, fisicamente separadas, com controle de acesso distinto, e idealmente imutáveis, ou seja, que não podem ser alteradas ou apagadas nem por quem tem acesso administrativo ao ambiente principal durante um período determinado. Essa separação de privilégios é o que garante que, mesmo com a rede principal comprometida, ainda exista um ponto de retorno íntegro.
| Critério | Ter backup | Ter plano de disaster recovery |
|---|---|---|
| Teste de restauração realizado | Raramente, ou nunca | Testado periodicamente em ambiente controlado |
| Tempo de recuperação (RTO) | Desconhecido ou estimado informalmente | Definido, documentado e validado na prática |
| Perda de dados aceitável (RPO) | Não formalizada | Definida por sistema e por criticidade do dado |
| Cópia isolada ou imutável contra ransomware | Geralmente ausente | Parte obrigatória da arquitetura |
| Documentação do processo de recuperação | Inexistente ou desatualizada | Passo a passo revisado e acessível à equipe |
Falhas comuns que só aparecem na hora da recuperação
- Backup nunca foi restaurado em um teste real: a rotina de cópia roda todas as noites sem erro aparente, mas ninguém jamais tentou reconstruir um servidor ou um banco de dados inteiro a partir dela. Falhas de compatibilidade, arquivos corrompidos ou backups incompletos só aparecem quando é tarde demais para corrigir, geralmente no meio de uma crise já em curso.
- A cópia de backup fica na mesma rede vulnerável ao mesmo ataque: se o backup está acessível a partir do mesmo domínio, com as mesmas credenciais administrativas do ambiente de produção, um invasor que compromete a rede compromete também a via de recuperação, tornando o backup inútil no cenário em que mais seria necessário.
- Ninguém sabe quanto tempo levaria para restaurar de fato: sem um RTO testado, a estimativa de algumas horas pode, na prática, significar dias, tempo em que a operação da empresa, o atendimento a clientes e o faturamento ficam paralisados sem previsão confiável de retorno, e a diretoria descobre isso apenas durante o próprio incidente.
- O backup cobre o servidor, mas não cobre os sistemas SaaS e de nuvem usados no dia a dia: planilhas em nuvem, CRM, ERP hospedado por terceiros e ferramentas de e-mail corporativo frequentemente ficam fora do escopo do backup tradicional, sob a premissa equivocada de que o fornecedor já cuida disso, quando, na maioria dos contratos, o fornecedor cuida apenas da própria infraestrutura, não dos dados apagados por erro do cliente.
- O processo de restauração depende de uma única pessoa: quando o conhecimento de como executar a recuperação está na cabeça de um único profissional de TI, a ausência dessa pessoa no momento do incidente, por férias, desligamento ou indisponibilidade, transforma um problema técnico em uma crise organizacional que se arrasta enquanto a empresa espera alguém reaprender, no improviso, um processo que nunca foi documentado.
A razão por trás dessa posição é simples: o custo de testar um backup é previsível e baixo, enquanto o custo de descobrir que ele não funciona durante um incidente real é, na prática, incalculável, envolve receita perdida, clientes insatisfeitos, possível exposição regulatória sob a LGPD em caso de vazamento e, em alguns casos, dados que simplesmente não voltam nunca mais. A maturidade de uma estratégia de recuperação não se mede pela existência da cópia, mas pela confiança verificável de que ela funciona quando for necessária, e essa confiança só existe depois de um teste real, feito antes do incidente, não durante ele.
Vale notar ainda que o teste de restauração tende a revelar problemas que passam despercebidos por anos: versões de sistema incompatíveis com o backup mais recente, credenciais de acesso expiradas, ou volumes de dados que cresceram tanto que o tempo de restauração estimado originalmente já não corresponde à realidade atual da empresa. Esses ajustes só aparecem quando alguém efetivamente tenta restaurar, e por isso o teste periódico não é uma formalidade, é o único mecanismo que transforma uma suposição em um fato verificado.
Como a Vetor Advisory trata backup e disaster recovery na prática
Dentro do trabalho de Governança de TI, a Vetor Advisory trata backup e disaster recovery como parte da estrutura de controle da empresa, não como um item isolado de infraestrutura. Isso significa definir, junto à diretoria e à equipe de TI ou fornecedor responsável, quais sistemas são críticos, qual RTO e RPO fazem sentido para cada um deles considerando o impacto real no negócio, e qual arquitetura de cópias, incluindo isolamento e imutabilidade, é adequada ao porte e ao orçamento da empresa.
O trabalho não termina na definição da política. A governança de TI estabelece também a rotina de teste periódico de restauração, a documentação do processo de recuperação de forma acessível a mais de uma pessoa, e a revisão regular desses controles à medida que a empresa cresce, muda de fornecedores ou passa a depender de novos sistemas em nuvem. É esse ciclo, definir, testar, documentar e revisar, que transforma um backup em uma capacidade real de recuperação de desastres, e é esse ciclo que garante que, quando o incidente finalmente acontecer, a resposta da empresa seja um processo conhecido, não uma improvisação sob pressão.