Continuidade e Recuperação: O Restore que Ninguém Testou

Todo painel de backup mostra checkmarks verdes. Jobs completados, política de retenção satisfeita, armazenamento utilizado conforme esperado. Nada disso diz se você consegue trazer um domain controller de bare metal em menos de quatro horas durante um incidente real. O vão entre "backup bem-sucedido" e "restore bem-sucedido" é onde a maioria dos planos de continuidade silenciosamente falha.

Por que o checkmark mente

Software de backup relata sucesso quando termina de escrever bytes em um destino. Ele não sabe se esses bytes são utilizáveis. Um backup de SQL Server pode completar limpo e ainda ser irrestaurável porque a cadeia de transaction log quebrou três dias atrás e ninguém notou. VM snapshots podem parecer corretos no console enquanto o VSS writer subjacente silenciosamente falhou dentro do guest OS, produzindo uma imagem crash-consistent (não application-consistent).

Operadores de ransomware sabem disso. Grupos rodando playbooks estilo Conti em incidentes passados deliberadamente direcionaram infraestrutura de backup — deletando shadow copies com vssadmin delete shadows /all /quiet, desabilitando repositórios Veeam, criptografando alvos de backup baseados em NAS que eram acessíveis por SMB. Se seus backups vivem no mesmo segmento de rede que produção com credenciais de domínio que podem tocá-los, eles são um alvo, não uma rede de segurança.

Construa um runbook de restore, não uma política de backup

Um plano de continuidade precisa de instruções de restore passo a passo escritas para alguém que não é a pessoa que normalmente faz isso. Anote:

• Ordem exata de recuperação (domain controllers e DNS primeiro, depois apps principais, depois tudo mais)
• Onde credenciais do console de backup vivem se seu password vault também está down
• O comando de restore específico ou caminho de console, não "use Veeam para restaurar a VM"
• Duração esperada por sistema, baseada em testes realmente medidos, não números de marketing do vendedor

Para Veeam Backup & Replication, isso significa documentar os passos reais: abrir o console, navegar até Backups > Disk, clique direito no restore point, escolha Instant VM Recovery ou Full VM Restore dependendo do cenário, e selecione o host alvo com capacidade livre suficiente. Se seu host primário também está comprometido, você precisa de um segundo host, isolado, já identificado e licensiado.

Teste restores em um cronograma, não por capricho

Escolha uma rotação. Todo mês, restaure um sistema crítico para uma VLAN isolada e valide que ele bota, autentica, e serve dados corretamente. Todo trimestre, rode um teste de escopo completo: restaure seu domain controller, seu file server, e seu banco de dados primário para infraestrutura isolada, depois peça para alguém fora do time de backup tentar fazer login e puxar um relatório.

Para bancos de dados, não apenas restaure o arquivo .bak — verifique-o:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

Depois efetivamente restaure-o para uma instância de teste e rode DBCC CHECKDB contra ele. Um backup que passa VERIFYONLY ainda pode conter corrupção lógica que só aparece quando você o consulta.

Para sistemas Linux usando algo como Bacula ou restic, teste o caminho de restore real:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Depois diffar os arquivos de config restaurados contra produção para confirmar que nada silenciosamente caiu.

Cópias imutáveis e a regra 3-2-1-1

A regra clássica 3-2-1 (três cópias, dois tipos de mídia, um offsite) precisa de uma atualização para a era de ransomware: 3-2-1-1, onde o "1" extra é uma cópia imutável ou air-gapped. Object lock em armazenamento compatível com S3 (Wasabi, Backblaze B2, ou AWS S3 com Object Lock habilitado) previne exclusão ou modificação por uma janela de retenção definida, mesmo por uma conta com credenciais de admin. Configure-o com:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Modo COMPLIANCE significa que ninguém, incluindo a conta root, pode encurtar retenção ou deletar objetos cedo. Isso importa quando o atacante tem domain admin.

Meça RTO e RPO com números reais, não suposições

Recovery Time Objective e Recovery Point Objective parecem exercícios de papelada até um executivo perguntar "quanto de dados perdemos e quanto tempo ficamos down." Cronometrize seus últimos três test restores. Se seu objetivo de RPO é uma hora mas seu job de backup apenas roda a cada seis, você tem um vão documentado, e é melhor encontrar esse vão em um exercício de tabletop do que durante um evento real de criptografia às 2 da manhã em um sábado.

Rode o teste, anote a hora real do relógio, e compare com o que você prometeu no documento de disaster recovery. A diferença entre esses dois números é o estado real do seu plano de continuidade.

Para mais sobre hardening dos sistemas que você está protegendo e construir workflows de incident response, veja os segmentos relacionados de Blue Team e Digital Forensics no Korra Studio.