A pergunta que de facto importa sobre as suas cópias de segurança não é «estão a ser feitas?». É «quando foi a última vez que restauraram uma a sério?». Nas auditorias, à primeira responde-se com um sim tranquilo e à segunda com um silêncio incómodo. Esse silêncio é o buraco: uma cópia que corre todas as noites sem dar erro parece uma cópia que funciona, e nem sempre é. Só sabe quando a restaura.
Este artigo é sobre a parte que quase ninguém faz: testar o restauro das cópias de segurança. Montar o ensaio, cronometrá-lo e encontrar o que falha a frio, não no dia do incêndio. Porque a cópia que nunca foi restaurada não é uma cópia: é uma promessa por verificar.
A cópia que nunca foi restaurada não é uma cópia
Um trabalho de cópia que termina a verde diz-lhe uma só coisa: que uns dados foram lidos e escritos noutro sítio. Não diz que estão completos, que o ficheiro não está corrompido, que a base de dados é consistente nem que consegue arrancar um sistema com eles. O «verde» mede a escrita, não a sua capacidade de recuperar. Confundi-los é a falsa sensação de segurança mais cara que existe em IT.
O dia em que precisa de restaurar nunca é uma terça-feira tranquila. É às três da manhã, com o ransomware já lá dentro ou o servidor sem arrancar e a direção a perguntar quando se volta a faturar. O pior momento para descobrir que a cópia da base de dados estava a meio, que faltava uma pasta ou que restaurar 2 TB pela sua linha demora três dias. O teste de restauro existe para que essas descobertas aconteçam hoje, a frio e sem custo, e não nessa altura.
Ninguém tem um problema de cópias de segurança. Toda a gente tem um problema de restauros. Só que a maioria ainda não sabe.
O que é um teste de restauro e com que frequência fazê-lo
Um teste de restauro é recuperar a fingir para saber que no dia a sério consegue mesmo: pega numa cópia, levanta-a num ambiente controlado e verifica que os dados estão lá, são consistentes e o sistema funciona. Não é olhar para o relatório nem confirmar que o ficheiro pesa o esperado; é tocar nos dados recuperados e confirmar que servem. E nem todos são iguais: cada nível testa uma coisa diferente e tem a sua frequência sensata.
- Restaurar um ficheiro ou pasta (mensal). O ensaio mais barato e o mais frequente na vida real: alguém apagou algo. Recupere um ficheiro de há uma semana e um de há um mês e confirme que abre. Valida a retenção, não apenas a cópia de ontem à noite.
- Restaurar uma caixa ou conta de correio (trimestral). Teste recuperar uma caixa completa ou mensagens concretas, sobretudo com Microsoft 365 ou Google Workspace, onde muita gente acredita — erradamente — que o fornecedor já lhe faz a cópia.
- Restaurar um servidor ou aplicação completa (trimestral ou semestral). Levantar o servidor de ficheiros, o ERP ou a base de dados em isolado e verificar que arranca e é coerente. É aqui que aparecem as dependências esquecidas: serviços que não sobem, licenças, ligações a outras máquinas.
- Recuperação bare-metal ou do ambiente inteiro (anual). Reconstruir de raiz, como se não restasse nada. O simulacro de desastre a sério: é aqui que se mede de facto o seu RTO e saem os tempos que ninguém tinha cronometrado.
A regra prática: quanto mais crítico e difícil de reconstruir, mais vezes se testa. E sempre que muda algo relevante — um servidor novo, uma migração — há que repetir o ensaio. Uma cópia que funcionava em janeiro pode estar partida desde a migração de março sem que ninguém dê por isso.
Como montar um teste de restauro a sério
Um teste mal feito dá uma tranquilidade ainda pior do que não testar. «Abri um PDF da cópia e via-se» não prova nada. Um ensaio a sério faz-se num ambiente isolado, segue um guião e produz um número medido, não uma sensação. Esta é a nossa checklist:
- Ambiente isolado, nunca produção. Restaura-se numa rede ou máquina separada, sem tocar nos sistemas vivos. Restaurar sobre a produção «para ver se vai» é a melhor forma de transformar um ensaio num incidente real.
- Partir do cenário, não do ficheiro. Defina que desastre simula: apagamento acidental, servidor perdido, ransomware que cifrou a produção e as cópias acessíveis. Restaure como faria nesse dia real.
- Verificar o dado, não que «existe». Que a base de dados abra e seja consistente, que os números batam certo, que a data da cópia seja a esperada. Um ficheiro restaurado que não abre é um ficheiro perdido com mais passos.
- Cronometrar o RTO a sério. Meça desde «decidimos restaurar» até «o serviço está utilizável», incluindo o que ninguém conta: descarregar a cópia de fora, decifrar, reinstalar, reconfigurar. Esse relógio é o seu RTO real, não o do folheto.
- Confirmar o RPO real. Verifique quantas horas de trabalho perde com a cópia que usou. Se copia uma vez por dia, o pior caso são 24 horas. Que esse número seja conhecido e aceite pela direção, por escrito.
- Documentar e comparar com o acordado. Deixe registo do resultado e confronte-o com o RTO/RPO que a empresa disse poder aguentar. Se o plano diz oito horas e o teste diz vinte e seis, tem um problema para resolver hoje, com calma.
Este último ponto é o que torna o exercício útil. Sem um RTO e um RPO acordados com a direção, o teste não tem contra o que medir-se e fica em anedota técnica. Com eles, cada ensaio diz-lhe se está dentro ou fora da margem que o seu negócio aguenta.
Erros típicos que só se veem ao restaurar
Há falhas que nenhum relatório de cópia deteta, porque não ocorrem ao copiar, mas ao recuperar. São invisíveis até ao dia em que restaura; por isso o ensaio tira-as cá para fora antes de fazerem estragos.
- Cópias incompletas. A cópia faz-se, mas não inclui tudo: falta uma base de dados, uma pasta partilhada ou o servidor que foi acrescentado há oito meses e ninguém meteu no trabalho. A verde a vida toda; recupera e falta justamente o que importava.
- Dependências esquecidas. Restaura a aplicação e não arranca porque lhe falta um serviço, uma versão, um certificado ou a máquina vizinha com quem falava. Recuperar um sistema quase nunca é recuperar um só servidor.
- Cifragem e chaves perdidas. A cópia está cifrada — bem — mas a chave estava no mesmo servidor que se perdeu, ou ninguém sabe onde vive. Uma cópia que não consegue decifrar é ruído perfeitamente inútil.
- Dados inconsistentes. A cópia foi tirada com a base de dados em funcionamento e sem um dump consistente: o ficheiro está lá, mas corrompido ou a meio de uma transação. Só descobre ao tentar montá-lo.
- RTO real incomportável. Está tudo e está tudo correto, mas restaurá-lo pela sua linha de internet demora quatro dias e o negócio aguenta um. Tinha a cópia; não tinha o tempo.
Nenhum se resolve comprando mais discos. Resolvem-se a testar: só o ensaio os torna visíveis enquanto ainda os pode corrigir sem pressa nem perdas.
Como o faz a MagicBoxDesk
Testar restauros à mão, com critério e de forma periódica, é precisamente o tipo de tarefa que uma empresa ocupada com o seu trabalho nunca chega a fazer: importante, não urgente, até ao dia em que é urgentíssima. Por isso na MagicBoxDesk tratamos disso nós. O nosso backup gerido inclui restauros testados periodicamente: não lhe entregamos um software e lhe desejamos sorte, mas um serviço que responde pelo resultado. Levantamos as suas cópias em ambiente isolado consoante a criticidade, verificamos que os dados são consistentes, cronometramos o RTO real e entregamos-lhe um relatório com o que funciona e o que há que ajustar antes de ser um problema.
Tudo isto encaixa com a nossa monitorização 24/7, que vigia cada trabalho de cópia e avisa se algo falha — fica a saber por nós, não por um desastre —, e com o resto dos serviços de IT geridos que formam o seu IT externalizado. A diferença é concreta: passa de acreditar que está protegido para ter a prova, com data e tempos medidos.
Deixe de confiar que a sua cópia restaura e comprove-o. Peça um orçamento sem compromisso e montamos os testes de restauro da sua empresa para que no dia mau recupere a sério, não por fé.
