Como testar a restauração de backup na empresa

Para testar a restauração de backup na empresa, escolha uma atividade crítica, recupere uma cópia em ambiente isolado e peça à área usuária que execute uma tarefa de teste. Registre o horário dos dados recuperados e o momento em que a tarefa voltou a funcionar. Compare esses resultados com as metas de perda de dados e tempo de recuperação acordadas com a operação.

Imagine que o financeiro perdeu a pasta usada no fechamento do mês. O console indica que o backup terminou na madrugada. Isso ainda deixa três perguntas em aberto. A versão correta dos documentos está na cópia? A equipe autorizada consegue abrir os arquivos? Quanto tempo passa até que ela possa retomar o fechamento? Este roteiro mostra como responder às três sem sobrescrever os dados em uso.

Defina o cenário e o que conta como recuperação

Escolha um processo com impacto conhecido, como emitir pedidos, consultar documentos ou fechar a folha. Defina o incidente simulado, o horário de referência, os dados necessários e uma tarefa que o responsável da área consiga executar do início ao fim. Começar pela atividade ajuda a identificar o que uma cópia de arquivos ou uma imagem de servidor precisa entregar para ser útil.

Para uma pasta financeira, um critério de aceitação pode ser localizar os arquivos do fechamento, abrir planilhas de datas diferentes e confirmar as permissões de quem prepara e de quem aprova. Para um sistema de pedidos, pode ser localizar um pedido de referência, verificar itens e totais e emitir um relatório de teste sem acionar integrações reais. Anote o que o exercício exclui, como filiais, histórico antigo ou a retomada do ambiente de produção.

Meça tempo e perda de dados separadamente

O guia de contingência do NIST apresenta os conceitos de RTO e RPO no contexto da recuperação. Na prática, uma cópia íntegra pode ser antiga demais para o RPO. Também é possível recuperar os dados certos e ultrapassar o RTO porque o acesso demorou, o destino precisou ser criado ou a validação do sistema levou mais tempo que o previsto.

Prepare o ambiente de teste

Combine uma janela com as equipes que mantêm o backup, a infraestrutura e a aplicação. Registre quem pode iniciar, interromper e validar o exercício. Verifique a disponibilidade da cópia, o espaço para os dados restaurados e os acessos ao repositório. Se o backup estiver criptografado, confirme o procedimento autorizado para usar as chaves sem registrar seus valores na ata.

Em um teste de arquivos, escolha um destino com acesso restrito e caminho distinto da pasta original. Para bancos e servidores, use uma instância ou rede de teste segregada. Antes de iniciar a aplicação, desative o que possa afetar terceiros: envios de e-mail, conciliações automáticas, integrações que gravam em produção e tarefas agendadas. Verifique também nomes de máquinas, endereços e conexões para evitar que o ambiente recuperado se apresente como o original.

Proteja os dados e defina quando interromper

Prefira dados de teste quando eles representarem a situação. Se o exercício exigir dados reais, restrinja acesso e circulação, registre evidências sem expor informações pessoais e combine a limpeza do destino ao final. Interrompa o teste se o destino for ambíguo, o isolamento não puder ser verificado ou o procedimento exigir credenciais ou ações fora da autorização. Registre o impedimento para que a área responsável corrija a preparação.

Em um incidente de ransomware, a escolha de um ponto conhecido como íntegro e a liberação para conectar o sistema recuperado pertencem ao plano de resposta ao incidente. Um exercício de restauração ajuda a testar esse caminho. O guia da CISA sobre ransomware orienta manter cópias críticas protegidas e testar periodicamente a disponibilidade e a integridade dos backups.

Inclua as dependências que podem atrasar o início

Se o cenário simula a perda do ambiente principal, descubra se o catálogo dos backups, as instruções e os contatos continuam acessíveis por outro caminho. Combine como a equipe solicitará acesso de emergência e quem poderá autorizar o uso das chaves. Quando a cópia depende de um fornecedor, confirme quem pode abrir o chamado e como a equipe receberá os dados restaurados. Uma simulação feita com todos esses recursos já abertos mede a execução técnica em condições preparadas. Registre essa condição se quiser comparar o resultado com um cenário que começa sem o destino pronto.

Escolha a verificação certa para cada tipo de restauração

O resultado técnico precisa refletir o que foi restaurado. Uma pasta pronta para consulta, um banco pronto para responder a consultas e um servidor capaz de sustentar a aplicação exigem verificações diferentes. Use os critérios abaixo para combinar a evidência mínima do seu cenário com a área usuária.

Arquivos e pastas compartilhadas

Selecione uma amostra com extensões, tamanhos, datas e permissões diferentes. Inclua um arquivo cuja versão mais recente não seja a que precisa ser recuperada, como um documento alterado depois do fechamento. Compare a versão restaurada com o que o responsável espera e abra o arquivo no aplicativo de uso real. Quando houver um manifesto confiável de referência, use também a verificação de integridade prevista nele.

Confira permissões com os perfis do teste. A conta de administrador pode abrir um documento que o usuário da área não consegue acessar. Teste tanto um perfil autorizado quanto um perfil que deve ficar bloqueado, conforme a política aplicável. Se o repositório for um NAS, inclua no plano a dependência do equipamento e das credenciais. Veja também como avaliar se o backup em NAS é suficiente para a empresa.

Banco de dados e ponto no tempo

Defina se o objetivo é recuperar uma cópia completa ou voltar a um ponto anterior a uma exclusão ou alteração. O segundo cenário depende do mecanismo do banco e da disponibilidade da cadeia necessária. Por exemplo, no PostgreSQL com arquivamento contínuo, a recuperação física a um ponto no tempo usa um backup base e os segmentos de WAL necessários. No SQL Server, a recuperação a um ponto no tempo depende do modelo de recuperação e da sequência de backups disponível. A equipe deve seguir a documentação da versão utilizada. PostgreSQL e Microsoft Learn detalham esses mecanismos.

Restaure em uma instância de teste e registre o ponto efetivamente atingido. Verifique a consistência com os recursos adequados do banco e rode consultas de leitura com resultados esperados, como contagem por período ou conferência de um conjunto de pedidos conhecido. Se a aplicação fizer parte da validação, aponte uma instância de teste para o banco restaurado. Uma ferramenta que conseguiu ler o arquivo de backup indica que a mídia passou por uma verificação. A consulta bem-sucedida no banco restaurado e a tarefa de negócio são evidências adicionais e distintas.

Servidor físico ou máquina virtual

Inicie a cópia com a rede isolada e identifique os componentes necessários para a aplicação funcionar. Dependendo do ambiente, isso pode incluir volumes, permissões, DNS, certificados, banco de dados, contas de serviço e compartilhamentos. Confira a sequência de inicialização. Um servidor pode subir corretamente e deixar o serviço principal indisponível porque depende de um componente que ainda não foi restaurado.

Simule a tarefa escolhida com os acessos previstos e sem liberar integrações de produção. Se for necessário obter recursos adicionais, registre quanto tempo isso levou e se estava dentro do cenário. Para recuperar um sistema crítico em infraestrutura alternativa, use o plano de continuidade de TI para decidir quais recursos precisam voltar primeiro e quem autoriza a retomada.

Execute o teste em cinco etapas

Exemplo hipotético. Em uma falha simulada às 10h, a equipe recuperou o ponto das 8h30. A perda potencial foi de 1h30. Com RPO de 2h, o objetivo foi atendido. A área validou o trabalho às 11h15, 1h15 após o início do cenário. Com RTO de 1h, o teste ficou fora do tempo por 15 minutos. O resultado registra os dois critérios separadamente. Vale investigar em qual etapa se perdeu tempo antes de decidir o que corrigir.

Registre o resultado e planeje o reteste

Use o chamado ou a ata para guardar o contexto e as evidências necessárias para repetir o exercício. Um registro útil permite que outra equipe identifique a cópia, refaça a conferência e descubra quais pré-requisitos estavam disponíveis no dia. Indique se a evidência é um log técnico, um resultado de consulta ou uma validação da área usuária. Retire dados sensíveis antes de anexar capturas.

Modelo de registro do exercício

• Escopo: processo, recurso, cenário, data, fuso, executor, validador e itens fora do teste.
• Cópia e destino: identificador da cópia, ponto escolhido, ponto recuperado, ambiente de destino e confirmação de isolamento.
• Horários e metas: início do cenário, fim da restauração, hora da validação, RTO e RPO definidos e valores observados.
• Evidências e resultado: verificações realizadas, resultados esperados e observados, pendências e aprovação por critério.
• Encerramento: limpeza do ambiente, correção prevista, responsável, prazo e cenário para o reteste.

Se faltou acesso à cópia ou o ambiente demorou a ficar pronto, revise a etapa que mais consumiu tempo e repita o cenário com os mesmos critérios. Se a cópia era antiga demais, investigue cobertura, frequência, alertas e disponibilidade dos pontos previstos. Se faltou validar uma tarefa de negócio, reserve a participação da área no próximo teste. Mantenha o resultado inicial e o do reteste para mostrar o que mudou.

Diferencie teste parcial de retomada completa

Imagine que a equipe tenha recuperado o banco e confirmado as consultas, mas que o sistema de pedidos ainda precise de um serviço de autenticação ausente no teste. Registre o banco como validado dentro do escopo e a retomada do sistema como pendente. Use essa distinção para decidir se vale repetir o teste com autenticação e aplicação juntas. Em uma falha real, religar integrações ou transferir usuários para o ambiente recuperado requer uma decisão própria, com verificação das dependências e dos dados criados desde o ponto recuperado. O relatório do exercício oferece evidências para essa decisão e indica quais partes ainda precisam ser testadas.

Ao comparar dois exercícios, confira se o volume restaurado, a infraestrutura de destino e a tarefa final eram equivalentes. Um teste menor pode terminar mais rápido porque recuperou menos dados. Se o escopo mudou, descreva a diferença ao lado do tempo medido para que a equipe consiga interpretar o resultado.

Por onde começar

Escolha um processo crítico e agende um teste que caiba na janela disponível. Saia do exercício com um ponto de recuperação confirmado, um tempo medido e uma decisão por critério. Use o primeiro resultado para priorizar correções e ampliar o próximo teste para as dependências que ainda ficaram de fora.

Perguntas frequentes

Posso testar a restauração sem parar a empresa?

Em muitos casos, sim. Restaure para um destino separado e controle a rede, as permissões e as integrações. Combine a janela se a leitura do backup compartilhar recursos com a operação.

Restaurar um arquivo comprova que consigo recuperar o servidor?

Comprova a recuperação daquele arquivo nas condições testadas. Para avaliar um servidor ou sistema inteiro, valide também a inicialização, as dependências, os acessos e uma tarefa realista no ambiente de teste.

Com que frequência devo testar a restauração?

Defina a frequência pela criticidade dos dados, pelo impacto da parada e pelas exigências aplicáveis à operação. Repita o teste quando mudanças relevantes afetarem o caminho de recuperação ou depois de corrigir uma falha encontrada.