Existe uma frase que aparece em quase toda investigação de incidente, sempre no mesmo tom de alívio: "tudo bem, a gente tem backup."

E existe a frase que vem algumas horas depois, em outro tom: "a gente achava que tinha."

O problema não é fazer backup. É nunca ter voltado.

Backup é a única parte da infraestrutura que quase todo mundo configura e quase ninguém verifica. O job roda, o log diz "sucesso", o painel fica verde — e é exatamente isso que cria a falsa sensação.

Num caso que investigamos, numa operadora de saúde, o backup existia e rodava todo dia, em nuvem. A restauração nunca tinha sido testada. Quando o ransomware chegou, descobriram três coisas ao mesmo tempo: o backup não cobria um dos sistemas críticos, a restauração levaria mais tempo do que o negócio aguentava parado, e o próprio backup estava alcançável a partir da rede comprometida.

Os quatro jeitos de um backup falhar

1. Cobertura incompleta. Salva o banco, mas não a configuração; salva o servidor, mas não o bucket. Descobre-se na hora de subir.
2. Restauração nunca exercitada. Ninguém sabe quanto tempo leva. E o tempo é o que define se o negócio sobrevive.
3. Backup alcançável pelo atacante. Se a mesma credencial que administra a produção também administra o backup, o ransomware apaga os dois.
4. Retenção curta demais. Invasor costuma ficar semanas antes de disparar. Se você só guarda 7 dias, seu backup já está contaminado.

A regra 3-2-1-1-0

É a evolução da clássica 3-2-1, e vale decorar:

• 3 cópias dos dados
• 2 mídias diferentes
• 1 cópia fora do site
• 1 cópia imutável ou offline — que nem o administrador consegue apagar
• 0 erros na verificação de restauração

O 1 imutável e o 0 erros são os que a maioria pula. São também os dois que decidem o resultado no dia do incidente.

Roteiro: teste o seu esta semana

1. Escolha o sistema mais crítico. Aquele que, parado, custa mais por hora.
2. Restaure num ambiente isolado. Não em produção, e não "conferindo o log" — subindo de verdade.
3. Cronometre. Compare com quanto tempo o negócio aguenta parado. Se a restauração leva 12h e a operação aguenta 4h, você tem um problema mesmo com o backup funcionando.
4. Confira a integridade. O sistema sobe, mas os dados estão consistentes? Faltou tabela? Faltou arquivo?
5. Teste a credencial. Quem administra a produção consegue apagar o backup? Se sim, corrija isso primeiro.
6. Documente e repita. Trimestralmente, no mínimo. E sempre depois de mudança grande de arquitetura.

Duas métricas que a diretoria entende

Traduza o teste em dois números e a conversa sobre investimento fica muito mais fácil:

• RTO — quanto tempo até voltar a operar.
• RPO — quanto de dado você perde no caminho.

"Nosso RTO real medido é de 11 horas e o negócio aguenta 4" é uma frase que aprova orçamento. "Precisamos melhorar o backup" não é.