Seu backup restaura? Só o teste de restauração diz
Backup é uma cópia. Recuperação é uma capacidade, e ela só existe depois de testada. Enquanto ninguém restaurou a cópia em um ambiente limpo, cronometrou o processo e conferiu o resultado, sua empresa tem uma suposição, não um plano. O teste de restauração é o que transforma uma coisa na outra.
Por que ter backup não é o mesmo que saber recuperar?
Porque a cópia prova só uma coisa: um arquivo foi escrito em algum lugar. Ela não prova que o arquivo abre, que está completo, que contém tudo o que a operação precisa, nem que alguém sabe o que fazer com ele às três da tarde de uma terça-feira com o sistema fora do ar.
Os modos de falha são banais. A rotina parou de rodar e ninguém foi avisado. A cópia ficou no mesmo servidor que caiu. A chave de criptografia estava com quem saiu da empresa. O painel que mostra "backup concluído" não enxerga nenhuma dessas falhas, porque mede se a cópia foi feita, e não se ela serve.
A cópia em si é infraestrutura e tem bons manuais. O que muda o resultado é a decisão que vem antes: o que precisa estar na cópia, quanto tempo a empresa aguenta esperar e quem confere se o resultado está certo.
O que as normas pedem além da cópia?
Pedem evidência. O guia da CISA recomenda manter backups offline e criptografados e testar regularmente a disponibilidade e a integridade deles em um cenário de recuperação de desastre. O motivo, segundo o próprio guia, é que muitas variantes de ransomware procuram backups acessíveis para apagá-los ou criptografá-los.
O guia de planejamento de contingência do NIST (SP 800-34) separa três atividades: teste, treinamento e exercícios. O teste valida a capacidade de recuperação. O exercício expõe lacunas do plano. E o documento trata a verificação da mídia de backup como rotina, para conferir que os arquivos sejam recuperados sem erro e sem perda de dados.
Nenhum dos dois textos indica uma ferramenta. Os dois exigem que alguém tenha restaurado de verdade.
O que a pesquisa brasileira mede e o que deixa de medir?
A pesquisa TIC Empresas 2025, do Cetic.br, perguntou às empresas se concordam com a frase "os sistemas informatizados da empresa possuem mecanismos adequados para proteger os dados pessoais". Responderam que concordam totalmente 59%, e outros 18% concordam em parte. Nas empresas de 10 a 49 pessoas, o índice de concordância total foi de 58%. O resumo executivo da mesma edição registra que 53% das empresas tinham política de segurança digital.
O indicador mede opinião sobre uma afirmação. Ele não pergunta se a empresa restaurou alguma cópia, e não precisa perguntar: é pesquisa de percepção, não auditoria. O ponto é outro. Confiança declarada e capacidade comprovada são duas medidas diferentes, e só a segunda aparece no dia do incidente.
Quais decisões o teste de restauração força?
Três, e nenhuma delas é técnica.
A primeira é qual sistema é a fonte da verdade de cada dado. Se o preço vive em uma planilha, o cadastro no ERP e o status do pedido em uma conversa de chat, a cópia do ERP restaura um terço da operação. O teste mostra o que ficou de fora porque ninguém tinha decidido onde aquele dado mora. Essa é a mesma raiz de migrar de planilhas sem parar a operação: enquanto o dado crítico não tem casa definida, nenhum procedimento de cópia o alcança.
A segunda é quanto dado e quanto tempo a operação aceita perder. A literatura de contingência chama esses limites de ponto objetivo de recuperação (RPO) e tempo objetivo de recuperação (RTO). Em português simples: até que hora do dia os registros precisam voltar, e em quantas horas o sistema precisa estar de pé. Quem responde é o dono da operação, não o fornecedor de infraestrutura.
A terceira é a ordem de retorno. A emissão de nota depende do cadastro, que depende do banco de dados, que depende de um acesso que só uma pessoa tem. Sem ensaio, essa cadeia aparece no meio do incidente.
Na Colo Saúde, a Yowpi começou o trabalho por uma auditoria porque ninguém sabia dizer o estado real de segurança da plataforma. O padrão é o mesmo: o que não foi verificado não tem dono, e o que não tem dono aparece no pior momento.
Como isso aparece em uma PME?
Imagine, como hipótese, uma empresa de manutenção industrial com 40 pessoas. O ERP guarda as ordens de serviço. A escala das equipes fica em uma planilha mantida pelo coordenador, no notebook dele. A rotina de backup do ERP roda às duas da manhã e o painel mostra sucesso todos os dias.
Numa terça, às três da tarde, o servidor do ERP falha. Os números a seguir são ilustrativos, não uma medição. A cópia mais recente tem 13 horas de idade, então as ordens abertas e fechadas desde a madrugada somem. A restauração, que todos imaginavam levar uma hora, leva seis, porque ninguém sabia a senha do banco. E a escala das equipes não estava na cópia, então despachar o dia seguinte vira ligação para cada técnico.
Nada disso é falha de tecnologia. A cópia funcionou exatamente como foi configurada. Faltaram três decisões que o teste teria forçado: a planilha entra no escopo ou deixa de existir, o limite de 13 horas é aceitável ou não, e a senha do banco tem mais de um responsável. A inspeção mensal de sistemas internos já pede um restore recente. O teste de restauração é o que mostra o que esse restore revela.
Como fazer o primeiro teste sem parar a operação?
Escolha um sistema, de preferência o que interrompe o faturamento se parar. Restaure a cópia mais recente em um ambiente separado, nunca por cima da produção, e cronometre do início ao fim, incluindo o tempo de achar senhas e chaves.
Peça a quem opera o sistema que confira alguns registros recentes e um relatório já fechado. A pergunta é simples: isso está certo? Anote três coisas: quanto tempo levou, qual a idade do dado mais recente que voltou e o que faltou. Defina um dono e a data do próximo teste. O primeiro resultado pode ser desconfortável, e é para isso que ele serve.
Perguntas frequentes
Minha equipe não tem especialista em TI. Dá para testar mesmo assim?
Dá. A parte técnica pode ficar com quem mantém o sistema, seja uma pessoa da casa ou um fornecedor. O que a empresa não pode delegar é a definição do que é "certo": só quem conhece a operação sabe dizer se o relatório restaurado bate com a realidade. O primeiro teste exige mais conhecimento do negócio do que de infraestrutura.
Vale o esforço se eu nunca tive um incidente?
Sem um incidente anterior, a empresa não tem como saber o tamanho da perda que enfrentaria. O teste é a forma de descobrir isso sem esperar o incidente. Ele custa algumas horas de quem conhece a operação e um ambiente separado para a restauração. A conta de quanto vale evitar a surpresa é sua, e o teste é o que fornece os números para ela.
Meus dados estão em vários sistemas e planilhas. Por onde começo?
Pelo sistema cuja parada interrompe o faturamento. O teste vai mostrar as dependências que estavam fora do mapa, e esse mapa já é o primeiro ganho. Depois, repita com o próximo sistema da lista. Se o mapa revelar que dados críticos vivem em lugares que nenhuma rotina alcança, a conversa deixa de ser sobre backup e passa a ser sobre onde cada dado deveria morar.
O próximo passo
Se o teste mostrar que a sua operação depende de dados que nenhum sistema controla, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, é o lugar para mapear isso: fale com a Yowpi.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico