Preciso testar meu plano de backup
Resposta rápida
Backup não testado é fé, não é proteção. Estabeleça calendário de teste de restauração: mensal para sistemas críticos (banco do ERP, sistema fiscal, base do cliente), trimestral para sistemas relevantes, anual para o restante. Para cada teste: escolha um item da rotina (não escolha sempre o mais fácil), restaure em ambiente isolado, valide integridade (registros consistentes, totais batendo, aplicação acessando), meça RTO real (quanto tempo levou de fato) e RPO real (qual a última transação preservada), compare com o objetivo e documente. RTO e RPO no papel não valem nada quando o desastre acontece e o tempo descobertto é o triplo do prometido. O teste é o que separa backup que protege de backup que existe.
Na empresa pequena, backup costuma ser configurado e esquecido — o MSP cuida, "está rodando", e ninguém testa restauração até o dia em que precisa. O ritual mínimo viável: trimestralmente, restaurar um arquivo aleatório do servidor de arquivos para confirmar que o backup está íntegro; semestralmente, restaurar o banco do ERP em ambiente isolado (uma máquina virtual ou notebook reservado) e validar que abre. Pode ser feito em uma manhã. Se o MSP cuida do backup, exija o relatório do teste de restauração — não basta o relatório de execução do backup; o teste é separado. O risco específico desse porte é confiar 100% no MSP sem validação independente. Quando o desastre acontece, descobrir que o backup nunca foi testado é o pior momento para descobrir.
Na empresa média, o ambiente tem mais sistemas críticos, e a disciplina de teste passa a ser cadenciada por sistema. Mensal para os mais críticos (ERP, banco principal, sistema fiscal, e-mail), trimestral para os relevantes, anual para os secundários. O time de TI executa o teste em ambiente segregado (homologação, recuperação dedicada ou cloud sob demanda), mede RTO real e compara com o objetivo acordado. Aqui aparece com frequência uma surpresa: o backup roda, restaura, mas a aplicação não sobe porque o procedimento de restauração não cobre dependências externas (configuração de DNS, certificados, integrações). Por isso o teste vale ser realista — restauração completa do serviço, não só do dado. Plano de DR (Disaster Recovery) começa a fazer sentido nesse porte para cenário de perda de site completo.
Na empresa grande, teste de backup integra ao programa de continuidade de negócio com DR formal, runbooks por sistema, exercícios de mesa anuais e exercícios reais (failover controlado) periódicos. Automação parcial via ferramenta de backup enterprise (Veeam, Commvault, Rubrik, Cohesity ou similares) executa testes de restauração automatizados em ambiente sandbox para validar integridade sem intervenção manual. O risco aqui é o "teste de teste" — automação confirma integridade técnica mas o exercício de mesa raramente acontece, e quando o desastre real chega, descobre-se que o runbook está desatualizado e o time não executa há meses. Métrica importante: percentual de sistemas críticos testados no semestre, RTO real vs RTO objetivo, lições documentadas de cada teste.
- Backup roda todo dia mas nunca foi testado em restauração real
- Você não sabe quanto tempo leva para restaurar o sistema mais crítico
- RPO e RTO existem no papel mas nunca foram medidos na prática
- Quando precisou restaurar algo, foi descoberto que faltava algum dado
- O procedimento de restauração não está escrito em lugar nenhum
- Confia no relatório de execução do backup sem validar conteúdo
RPO e RTO em linguagem simples
Dois conceitos governam todo plano de backup, e entendê-los bem evita decisão errada de investimento.
RPO (Recovery Point Objective): quanto de dado a empresa aceita perder. Se o backup roda uma vez ao dia, o RPO é até 24 horas. Se roda a cada hora, RPO de até 1 hora. RPO menor exige backup mais frequente, mais armazenamento, mais custo. A pergunta para definir: quanto custaria perder o último X de horas de informação? Para banco transacional, quase nada é aceitável. Para repositório de arquivos com mudança baixa, dias podem ser aceitáveis.
RTO (Recovery Time Objective): quanto tempo a empresa aceita ficar sem o sistema. RTO de 1 hora exige infraestrutura de DR pronta para assumir; RTO de 24 horas aceita restauração tradicional. RTO menor exige investimento maior. Pergunta para definir: quanto custa cada hora de indisponibilidade desse sistema?
RPO e RTO definidos por sistema, com base em impacto. Faz pouco sentido aplicar o mesmo objetivo a tudo — perde-se dinheiro protegendo o irrelevante e fica-se desprotegido onde importa.
O backup tem que ser 3-2-1
Regra prática consagrada: três cópias dos dados, em dois tipos diferentes de mídia, com uma cópia fora do site. Sem essa diversificação, um único evento (incêndio, ransomware, falha de hardware) pode levar todas as cópias. Cloud como cópia off-site cumpre bem essa função para empresas de qualquer porte.
- Escolha o que testar. Para sistemas críticos, alterne entre componentes (banco, configuração, aplicação completa). Não teste sempre o mais fácil — o desastre vem pelo mais difícil.
- Reserve ambiente isolado. Máquina virtual, ambiente de homologação ou cloud sob demanda. Nunca teste restauração em produção — risco enorme de sobrescrever dado bom.
- Documente o ponto de partida. Que backup será restaurado? De quando? Quem executa? Quanto tempo se planeja?
- Execute o procedimento. Siga o runbook escrito. Onde o runbook fica vago ou errado, anote — é o aprendizado mais valioso do teste.
- Meça o tempo real. Do início até o sistema responder normalmente. Inclua tempo de download/transferência do backup, restauração propriamente, reconfiguração, validação.
- Valide integridade. Não basta o sistema subir — totais batem? Últimas transações estão presentes? Aplicação consegue ler e escrever?
- Compare com objetivo. RTO real vs RTO planejado. RPO real (qual a última transação encontrada) vs RPO planejado.
- Registre resultado e ajustes. O que funcionou, o que falhou, o que precisa virar tarefa para corrigir antes do próximo teste.
O que normalmente falha em teste
Padrões previsíveis aparecem em quase toda primeira rodada de teste de restauração. Backup que roda mas grava em mídia que nunca foi acessada (corrompida quando precisa). Backup completo de banco que não inclui logs de transação (perde transações entre o full e o momento da falha). Backup de arquivo que não inclui as permissões e propriedade (restaura o conteúdo mas a aplicação não acessa). Backup de máquina virtual que não captura configuração de rede (sobe mas não comunica).
Encontrar esses padrões em teste controlado é vitória. Encontrá-los no desastre real é falha de uma ordem de magnitude maior. Por isso o teste vale o tempo investido — cada problema encontrado em teste é problema que não vai aparecer em crise.
Exercícios de mesa para o cenário de DR
Além do teste técnico de restauração, exercício de mesa periódico simula o cenário de desastre maior. Em uma sala, com o time de TI, áreas de negócio críticas e liderança, descreve-se um cenário (incêndio no data center principal, ransomware encripta produção, sequestro de credenciais executivas) e o time discute passo a passo o que faria. Não é teste técnico — é teste de processo, comunicação, decisão.
O que sempre aparece no exercício: lacunas em quem comunica o quê a quem, dependências não mapeadas (fornecedor que precisa ser contatado, banco que precisa ser avisado), processos não documentados que dependiam de uma pessoa específica. Exercício anual cobre o que o teste técnico não vê.
Confiar no relatório de execução. Backup que "rodou com sucesso" não significa backup íntegro — o relatório mede o processo, não o resultado. Só restauração testada valida.
Testar sempre o mais fácil. Quando o teste cobre só sistema simples, o difícil nunca foi validado. O desastre real escolhe o que está mais vulnerável, não o mais fácil.
Não medir o tempo real. RTO objetivo de 2 horas pode ser RTO real de 8 horas. Sem medir, o objetivo é ficção que vira problema na crise.
Backup acessível pelo admin do sistema. Ransomware com credencial vazada apaga o backup junto. Backup imutável ou em local sem credencial compartilhada é a defesa.
- RPO e RTO definidos por sistema com base em impacto
- Backup segue a regra 3-2-1 (três cópias, duas mídias, uma fora do site)
- Cópia off-site é imutável ou está fora do alcance de credencial padrão
- Teste de restauração realizado dentro do prazo do calendário
- RTO real medido e comparado com RTO objetivo
- Procedimento de restauração documentado em runbook escrito
- Lições do último teste viraram ajustes implementados
- Exercício de mesa de DR foi realizado nos últimos doze meses