Backup restaurável: por que testar a recuperação

Para verificar se um backup permite recuperar um serviço após ransomware, restaure uma cópia em ambiente isolado e execute a operação que esse serviço precisa oferecer. Confira a integridade dos dados, procure sinais de comprometimento e registre o tempo até a validação funcional. A cópia aparecer no catálogo ou terminar de transferir arquivos não encerra o teste.

Um backup pode estar disponível e ainda faltar uma configuração, uma chave ou uma versão íntegra dos dados. O guia do NCCoE para prestadores de serviços recomenda manter e testar cópias para reduzir o impacto de ransomware e outras perdas de dados. Para uma equipe pequena, um exercício mensal com escopo limitado e registro padronizado é uma forma prática de descobrir essas falhas antes de depender da cópia em um incidente.

Defina o serviço e o resultado esperado

Escolha um serviço essencial e descreva uma operação que demonstre sua recuperação. Se o sistema escolhido emite pedidos, por exemplo, abrir o banco de dados não basta: uma pessoa autorizada deve conseguir consultar os registros necessários e concluir um pedido de teste sem produzir efeitos reais. Delimite quais aplicações, dados e integrações fazem parte dessa operação.

Estabeleça com a área responsável o RTO, tempo máximo aceitável para recuperar o serviço, e o RPO, ponto até o qual os dados precisam ser recuperados. Anote o horário da interrupção simulada, o horário dos dados na cópia escolhida e o momento em que a operação voltar a funcionar. Assim, o exercício terá critérios definidos antes da restauração, em vez de declarar sucesso apenas porque os arquivos abriram.

Liste também as dependências: identidade e acesso, banco de dados, configurações, certificados, chaves, rede e serviços externos, conforme o caso. A orientação do NCSC sobre recuperação técnica inclui dados, aplicações, sistemas de identidade, infraestrutura de confiança e configurações entre os elementos a restaurar, além de recomendar o registro das dependências e da ordem de reinício. Essa ordem importa quando um componente recuperado só funciona depois de outro.

Isole a cópia e prepare o ambiente

Faça o ensaio fora da produção, em um ambiente limpo, com acesso restrito e credenciais destinadas ao teste. Desative ou bloqueie conexões que possam enviar e-mails, registrar pedidos reais, executar pagamentos ou sincronizar dados restaurados com sistemas ativos. Se uma integração externa for indispensável à validação, defina previamente uma alternativa segura e registre o que ela permite verificar.

Selecione uma cópia preservada e registre onde ela está, quando foi criada e como será obtida caso as contas ou máquinas habituais estejam indisponíveis. Restaure a partir dela sem modificar o exemplar protegido. Uma cópia acessível apenas pelo mesmo ambiente comprometido pode atrasar ou impedir a recuperação, mesmo que seu conteúdo esteja íntegro.

Voltado especificamente à tecnologia operacional, o NIST SP 1339 recomenda testes recorrentes de restauração em sistemas fora de produção, verificação de integridade por hash quando viável e atualização dos procedimentos após os exercícios. Para um serviço empresarial, a aplicação prática é testar a cópia em um sistema separado e conferir também se a função recuperada realmente opera. Um hash igual a uma referência confiável verifica a igualdade do conteúdo comparado; sozinho, não demonstra que a versão escolhida está livre de malware.

Execute a restauração na mesma sequência

Inicie a medição. Marque a decisão simulada de recuperar o serviço antes de localizar a cópia, obter acessos e preparar as chaves. Se o ambiente já estava montado, registre esse preparo separadamente; ele pode consumir tempo durante um incidente real.
Escolha o ponto de restauração. Indique por que a versão é anterior ao comprometimento simulado e qual é seu último dado esperado. Se ela apresentar falha ou indício de alteração, tente outra versão preservada e registre a perda adicional de dados.
Examine o material recuperado. Compare hashes quando houver referência confiável, consulte os registros disponíveis e use as ferramentas de detecção de malware adotadas pela equipe. Faça essa análise ainda no ambiente isolado. Um resultado sem alerta não substitui a investigação de sinais de comprometimento quando houver um ataque real.
Restaure as dependências. Siga a ordem prevista para identidade, banco de dados, aplicação e demais componentes necessários. Anote configurações, segredos, licenças e procedimentos que precisaram ser obtidos fora da cópia. A falta de qualquer item indispensável é um resultado do teste, mesmo que os arquivos principais tenham sido recuperados.
Valide a operação. Abra uma amostra de registros, confira sua consistência e execute a tarefa definida no início sem reconectar o ambiente à produção. Marque o horário em que o serviço passou a funcionar e registre quem confirmou o resultado funcional.

Meça tempo, perda e integridade

Compare o tempo entre a decisão simulada e a primeira operação funcional validada com o RTO definido. Separe a duração de cada etapa: obtenção da cópia, transferência, reconstrução, ajuste de dependências e validação. O tempo medido vale para o escopo e as condições do exercício; deixe explícito se acessos, equipamentos ou integrantes da equipe já estavam disponíveis.

Para avaliar o RPO, compare o horário da interrupção simulada com o último dado íntegro recuperado. Examine relações importantes entre registros, não apenas a presença de arquivos. Um pedido restaurado sem o pagamento correspondente, por exemplo, pode exigir conciliação antes que o serviço volte a ser usado. Se processos manuais gerarem novos dados durante a paralisação, registre como eles seriam integrados à versão recuperada.

Distinga integridade, segurança e funcionamento na avaliação. A comparação de hash ajuda a detectar mudanças em relação à referência usada; a análise de malware procura indícios conhecidos de comprometimento; a operação de teste mostra se os componentes recuperados trabalham juntos. Uma falha em qualquer dessas verificações deve constar no resultado, com o ponto de restauração e as condições em que ocorreu.

Registre o resultado em uma ficha curta

Use a mesma ficha em cada exercício: serviço e operação testados; responsável; data; localização e horário da cópia; motivo da escolha; isolamento aplicado; RTO e RPO definidos; horários de início e validação; último dado íntegro; verificações de integridade e malware; dependências ausentes; resultado funcional. Acrescente a causa de cada falha, quem ficará responsável pela correção e o prazo combinado.

Classifique a recuperação como aprovada apenas para o serviço, a versão e o cenário efetivamente testados. Na rodada seguinte, confira se as falhas corrigidas desapareceram e alterne o serviço ou o ponto de restauração para ampliar a cobertura. A ficha deve permitir responder, sem depender da memória da equipe, o que voltou a funcionar, quanto tempo levou e quais dados ficaram de fora.