Backup testado: o checklist que sua empresa deveria rodar antes de precisar

Você sabe se o backup da sua empresa realmente volta? A pergunta não é se “existe backup”. É se alguém já pegou aquela cópia, restaurou de verdade, e confirmou que o sistema liga de novo do jeito que deveria.

Se a resposta for “acho que sim” ou “nunca testamos”, você não está sozinho. Segundo a Unitrends, fornecedora de backup citada em várias análises do setor, cerca de 1 em cada 3 empresas nunca testou o próprio backup. Elas descobrem se funciona no pior momento possível: quando já precisam dele.

Ter backup e ter backup testado são coisas diferentes

Backup é uma rotina automática que copia dado pra outro lugar. Isso qualquer empresa configura numa tarde. Backup testado é quando alguém pegou essa cópia, restaurou num ambiente separado, e confirmou que o sistema volta a funcionar de ponta a ponta.

A diferença parece sutil até você imaginar o cenário: o servidor cai numa sexta às 18h, o time abre o painel de backup, tudo parece certo… e o restore trava na metade, ou volta com um arquivo corrompido de 3 semanas atrás. Nesse ponto, “ter backup” não ajudou em nada.

O que costuma dar errado quando ninguém testou

É comum o dono da empresa descobrir esse tipo de falha só quando já é tarde demais pra corrigir sem prejuízo. Os problemas mais frequentes não são exóticos:

• Arquivo salvo incompleto, sem ninguém perceber por meses
• Permissão de acesso configurada errada, que trava o restore justamente na hora
• Versão de sistema desatualizada, que não bate mais com o backup salvo há semanas
• Cópia que existe, mas nunca foi verificada, então ninguém sabe se está corrompida

Nada disso aparece enquanto o backup só está “rodando”. Só aparece quando alguém tenta trazer o dado de volta, e nesse momento já não sobra muito espaço pra improvisar. É por isso que o teste de restore virou parte obrigatória de qualquer fundação de infra AI-ready: dado sem confirmação de que volta não é dado protegido, é dado com sorte.

A regra 3-2-1 (e por que ela virou 3-2-1-1-0)

A regra clássica de backup é simples de lembrar: 3 cópias do dado, em 2 tipos de mídia diferentes, com 1 cópia fora do ambiente principal.

Na prática, pra uma empresa pequena isso costuma virar:

Cópia	Onde fica	Exemplo
Produção	Servidor ou máquina de trabalho	Sistema rodando no dia a dia
Local	Mídia separada, na própria rede	NAS dedicado pra backup
Offsite	Fora do ambiente físico	Backup em nuvem, criptografado

Com o avanço do ransomware, essa regra ganhou 2 números a mais: 3-2-1-1-0. O “1” extra é uma cópia imutável, que nem um invasor com acesso admin consegue apagar ou criptografar. O “0” é a meta de zero erros no último teste de restore documentado. A regra moderna já assume, de saída, que testar faz parte do processo, não um extra opcional.

O checklist de 4 fases pra testar restore de verdade

Testar restore não precisa ser complicado, mas precisa ser estruturado. O processo que funciona segue 4 fases:

1. Preparação: define o que vai ser testado (1 arquivo, 1 sistema inteiro, 1 banco de dados), separa um ambiente isolado pra restaurar sem mexer na produção, e junta a documentação de acesso que vai ser usada.

2. Execução: inicia o restore e cronometra do início ao fim. Esse tempo real é o seu RTO, o tempo de recuperação de verdade, não o que está prometido em algum contrato de fornecedor. Documenta cada etapa, incluindo o que deu errado.

3. Validação: confirma que o dado restaurado bate com o original (checksum, ou simplesmente abrir e checar), testa se o sistema funciona de ponta a ponta, e não só se os arquivos “estão lá”.

4. Documentação: registra escopo, resultado, tempo gasto e o que precisa mudar pra próxima vez. Sem esse registro, o teste vira memória de corredor e ninguém sabe quando foi feito pela última vez.

Frequência recomendada varia por criticidade. Teste rápido de 1 sistema específico pode ser mensal. Teste completo, simulando queda total, costuma rodar trimestral ou semestral. O que importa não é acertar a cadência perfeita. É sair do zero.

Como aplicar isso sem ter um time de TI dedicado

A maioria das empresas que atendemos não tem alguém de TI em tempo integral, e isso não é motivo pra pular o teste. O caminho mais simples:

1. Escolha 1 sistema crítico pra começar (o que mais dói se cair)
2. Marque uma data fixa no calendário, mesmo que seja só 1 vez por trimestre
3. Restaure numa máquina separada, nunca em cima da produção
4. Anote o tempo que levou e o que deu certo ou errado
5. Repita, e vá expandindo pros outros sistemas conforme o processo pega ritmo

O ponto não é fazer perfeito na primeira vez. É ter pelo menos 1 teste real documentado, porque isso já coloca a empresa à frente de boa parte do mercado.

Do lado técnico, não precisa reinventar nada: ferramentas como restic, Borgbackup ou Duplicati fazem a cópia local com deduplicação e criptografia, um job de cron ou n8n dispara o envio pra camada offsite (Backblaze B2, Wasabi ou outro provedor S3-compatible), e o próprio script de teste pode rodar automático, restaurando um subconjunto de dado numa máquina isolada toda semana. O trabalho manual fica só na validação e no registro.

Cuidados: quando isso ainda não é prioridade número 1

Nem toda empresa precisa de teste de restore semestral com simulação completa de desastre logo de cara. Se sua operação roda basicamente em planilha e WhatsApp, sem sistema próprio hospedando dado de cliente, o primeiro passo é mais simples: garantir que existe alguma cópia fora do computador principal, e testar essa cópia 1 vez. Só depois faz sentido pensar em cadência, automação e camada imutável.

O erro contrário também existe: empresa que compra uma solução de backup cara, empilha certificação em cima de certificação, e nunca chega a rodar o teste de restore de verdade porque “o fornecedor garante que funciona”. Ferramenta sofisticada sem teste tem o mesmo problema que ferramenta simples sem teste. Nenhuma das duas prova nada sozinha.

Quanto custa fazer isso direito

Pra uma empresa pequena, uma estrutura de backup com cópia local, cópia em nuvem criptografada e teste periódico documentado costuma ficar entre R$800 e R$2.000 por mês. É estimativa de mercado, varia com o volume de dado e quantos sistemas precisam entrar na rotina. Vale confirmar a faixa exata com quem for montar isso pra você.

Comparado ao custo de reconstruir dado perdido sem backup funcional (trabalho manual, sistema parado, cliente sem atendimento), a diferença de preço é a parte fácil da conta. A parte difícil é lembrar de fazer o teste antes que alguém precise dele de verdade.

Isso entra na fundação de infra AI-ready que a gente estrutura pros clientes: backup nas 3 camadas, rotina de teste com calendário fixo, e relatório documentado depois de cada rodada. Assim você tem resposta na mão se o auditor, o cliente ou o seguro perguntarem. Antes de qualquer IA entrar em cima da operação, essa fundação precisa estar de pé.

Conclusão

Backup sem teste é uma promessa não verificada. O checklist de 4 fases (preparar, executar, validar, documentar) transforma essa promessa em processo, com tempo real medido e resultado registrado. Não precisa ser complexo. Precisa ter dono e precisa rodar de novo, com regularidade, antes do dia em que você realmente precisar dele.

Se quiser ver como isso fica estruturado no seu caso, dá pra marcar um diagnóstico rápido e olhar sua situação atual de backup, sem custo pra descobrir onde estão os furos.