Backup que volta: como testar uma restauração de verdade

“O backup terminou” responde a uma etapa do processo. Para depender daquela cópia, falta saber se você consegue localizá-la, acessá-la e recuperar a versão necessária em condições úteis. Um teste de restauração transforma essa expectativa em um resultado que pode ser examinado.

Vamos fazer isso com um arquivo de texto fictício: guardar uma versão, modificar somente o arquivo de trabalho, restaurar a versão guardada em outra pasta e conferir o conteúdo. O exercício preserva os originais e produz um registro pequeno, com critérios definidos antes do teste.

Como uma cópia pode falhar junto com o original

No cenário de ransomware, um invasor pode procurar cópias acessíveis e destruí-las ou cifrá-las. O guia conjunto CISA/FBI/NSA/MS-ISAC recomenda backups offline e criptografados, com testes regulares de disponibilidade e integridade. Também alerta para sincronização que propaga arquivos alterados para a nuvem.^[1]

O mecanismo importante é a dependência compartilhada: original e cópia podem estar sujeitos à mesma conta, ao mesmo armazenamento ou ao mesmo evento de perda. Por isso, a pergunta “onde está o backup?” deve vir acompanhada de “o que ainda permite alcançá-lo se o ambiente principal falhar?”.

Sincronização e histórico de versões são características diferentes. No nosso exemplo, se uma atualização substitui a única cópia guardada, a versão anterior deixa de estar disponível por esse caminho. Verifique o comportamento do produto que você usa; o nome “nuvem” não descreve sua política de retenção ou recuperação.

Defina o que significa voltar a operar

Dois objetivos ajudam a formular requisitos:

São objetivos definidos conforme a necessidade, não propriedades automáticas do programa de backup. Se a última versão recuperável é de duas horas atrás, o exemplo de RPO de uma hora não foi atendido. Se o arquivo é copiado rapidamente, mas ninguém consegue abri-lo, o retorno útil ainda não aconteceu.

Para uma empresa, essa discussão envolve responsáveis pelo processo, prioridades, aplicativos e dependências. No laboratório a seguir, você vai verificar somente um arquivo de texto. O que observar nesse exercício não demonstra a recuperação de um banco de dados ou de um computador inteiro.

Prepare o laboratório

Para praticar, use Windows com PowerShell, o explorador de arquivos e um editor de texto. Você vai acompanhar cada cópia em pastas separadas. Crie uma pasta nova chamada ctw-restore-lab, fora das pastas de trabalho e de sincronização automática. Dentro dela, crie trabalho e restaurado.

Em uma unidade removível própria, crie uma pasta nova CTW-LAB com a subpasta reserva. Não formate a unidade nem substitua pastas existentes. Se só houver um disco disponível, use uma terceira pasta local e registre que o exercício verifica o procedimento lógico, sem testar sobrevivência à perda desse disco.

Use exclusivamente dados fictícios. Uma pasta em USB não implementa sozinha criptografia, retenção ou proteção de acesso; esses controles precisam ser escolhidos e testados separadamente antes de guardar dados reais.

No editor, salve pedido.txt dentro de trabalho, com este conteúdo:

VERSAO A
Itens: 3
Status: conferido

Ative a exibição de extensões no explorador para conferir que o nome não virou pedido.txt.txt. Abra o PowerShell na pasta ctw-restore-lab. Os comandos abaixo apenas leem arquivos e comparam valores; adapte caminhos quando indicado.

Guarde uma referência antes de alterar

1. Abra o arquivo de trabalho. Confira as três linhas e feche o editor. Anote que esta é a versão A que pretende recuperar.
2. Calcule a referência do conteúdo. Execute:

$ctwReferenceHash = (Get-FileHash -LiteralPath '.\trabalho\pedido.txt' -Algorithm SHA256).Hash
$ctwReferenceHash

O Get-FileHash calcula um resumo do conteúdo. Usaremos SHA-256 para comparar o arquivo antes e depois; o nome do arquivo não basta para essa verificação.^[4] Guarde o valor em seu registro e mantenha a sessão do PowerShell aberta durante o exercício.

3. Copie, sem recortar. Pelo explorador, copie pedido.txt para a pasta reserva criada na unidade de teste. Abra a cópia para conferir as linhas.
4. Confira a cópia guardada. No exemplo a unidade é E:; substitua esse caminho pelo caminho real que acabou de verificar:

(Get-FileHash -LiteralPath 'E:\CTW-LAB\reserva\pedido.txt' -Algorithm SHA256).Hash -eq $ctwReferenceHash

O resultado esperado é True. Se ocorrer erro ou aparecer False, pare e confira o caminho e o conteúdo antes de continuar. Quando estiver correto, ejete a unidade pelo sistema. Não deixe o teste depender de uma cópia ainda não conferida.

Restaure sem sobrescrever o trabalho

1. Crie uma diferença controlada. Edite somente trabalho\pedido.txt, substituindo VERSAO A por VERSAO B e Itens: 3 por Itens: 4. Salve e feche o editor. Essa mudança representa trabalho posterior ao backup; não é uma simulação de malware.
2. Inicie o registro de tempo. Anote o momento em que começa a buscar a versão A. Reconecte a unidade de teste e localize a cópia guardada.
3. Recupere em destino separado. Copie o arquivo da pasta reserva para ctw-restore-lab\restaurado. A pasta de trabalho permanece com a versão B.
4. Verifique o conteúdo recuperado. Abra restaurado\pedido.txt, confirme VERSAO A, três itens e o status. Feche o editor e execute:

(Get-FileHash -LiteralPath '.\restaurado\pedido.txt' -Algorithm SHA256).Hash -eq $ctwReferenceHash

5. Conclua a verificação funcional. O resultado esperado é True, e a versão A deve estar legível no editor. Anote o horário final, o local da cópia, a versão recuperada e qualquer dificuldade. Conte o tempo de localizar, copiar e verificar o arquivo. Se você não acompanhou a duração, registre “não medido” e cronometre uma próxima tentativa para poder comparar.

Compare expectativa e resultado

Tabela ilustrativa, sem medições reais ou resultados garantidos. Preencha a coluna de observação com o que aconteceu no seu exercício.

Interprete falhas antes de repetir

O hash divergiu: confirme a pasta, a versão e se o editor salvou alguma mudança. Não recopie automaticamente o arquivo de trabalho sobre a reserva; isso pode apagar a versão que você queria recuperar.

O comando não acha o arquivo: confira extensão, letra da unidade e caminho. Um erro de leitura é um teste incompleto, não uma comparação com resultado positivo.

A variável desapareceu: se fechou o PowerShell, recupere a referência que anotou antes da modificação. Não recalcule a referência usando a versão B e passe a chamá-la de versão A.

O conteúdo confere, mas o arquivo não abre: verifique aplicativo e permissões. Igualdade de hash não testa o ambiente de uso, a procedência ou a ausência de malware; ela sustenta uma comparação de conteúdo com a referência escolhida.

Feche o teste e ajuste o plano

Ejete a unidade, mantenha a versão B intacta e remova apenas as pastas fictícias quando não precisar mais do exercício. Registre as etapas que faltaram, como recuperação sem o computador original, disponibilidade das chaves ou restauração de aplicativos.

Uma restauração durante um incidente real também precisa evitar reinfectar sistemas recuperados.^[1] O ensaio acima é preparação em ambiente conhecido, não um roteiro completo de resposta a ransomware. Para entender outra dependência frequente da recuperação, leia contas, sessões e permissões.

Referências

1. CISA; FBI; NSA; MS-ISAC. #StopRansomware Guide. Versão 3.0, outubro de 2023. Parte 1, “Preparing for Ransomware and Data Extortion Incidents”; parte 2, etapa 19. Fonte. Consulta em 17 out. 2026. ↩ ↩²

2. NIST. Recovery Point Objective — CSRC Glossary. Definição atribuída à SP 800-34 Rev. 1. Fonte. Consulta em 17 out. 2026. ↩

3. NIST. Recovery Time Objective — CSRC Glossary. Definição atribuída à SP 800-34 Rev. 1. Fonte. Consulta em 17 out. 2026. ↩

4. MICROSOFT. Get-FileHash. Documentação do Windows PowerShell 5.1. Descrição, parâmetro LiteralPath e exemplos de comparação. Fonte. Consulta em 17 out. 2026. ↩