O backup que não existia: o que aprendi sobre disaster recovery antes de saber o nome
O backup estava configurado. Rodava toda noite. O problema: nunca tinha sido testado. Quando precisamos restaurar, descobrimos que o backup estava corrompido há semanas.
O HD do servidor de arquivos falhou numa sexta-feira à tarde.
Não foi gradual. Foi imediato — setor defeituoso no setor errado, sistema de arquivos corrompido, dados inacessíveis. Quatro anos de documentos de um departamento.
"Tem backup" — disse o responsável. "Roda toda noite."
Fomos verificar. O backup rodava. Os arquivos de backup existiam. Quando tentamos restaurar, descobrimos que o processo de backup tinha uma falha silenciosa há seis semanas — os arquivos eram criados, mas estavam corrompidos. Sem erro no log. Sem alerta. Só quando tentou restaurar: arquivo inválido.
Backup que não foi testado não é backup. É ilusão de backup.
Essa frase parece óbvia depois que você vive a situação. Antes, parece paranoia — o processo roda, o arquivo existe, por que testar?
Porque existência não é integridade. Porque processo automatizado pode falhar silenciosamente. Porque o momento em que você descobre que o backup não funciona é exatamente o momento em que você precisa que ele funcione.
O que mudamos depois desse incidente:
Teste de restore agendado. Uma vez por mês, restaurar um arquivo aleatório do backup e verificar se abre corretamente. Não o backup inteiro — um arquivo. O suficiente para confirmar que o processo está produzindo arquivos válidos.
Verificação de integridade no processo de backup. Após criar o arquivo de backup, verificar checksum. Comparar com checksum do original. Se diverge, gera alerta. Não deixar o processo terminar "com sucesso" sem confirmar que o resultado é válido.
Backup externo além do backup local. Backup no mesmo servidor que os dados originais não protege contra falha de hardware. Backup em storage separado. Backup offsite para desastre físico (incêndio, inundação). Regra 3-2-1: três cópias, dois meios diferentes, um offsite.
RTO e RPO são perguntas de negócio, não de TI. Recovery Time Objective: quanto tempo o negócio aguenta sem acesso aos dados? Recovery Point Objective: quantos dados o negócio aceita perder? Essas perguntas determinam a frequência do backup e o SLA de restore. Aprendi que backup é decisão de negócio disfarçada de decisão técnica.
Esse padrão — processo que parece funcionar mas não foi validado — aparece em software com outro nome.
Teste que passa mas não testa o que deveria testar. Alerta configurado para threshold que nunca dispara mesmo quando o sistema está degradado. Pipeline de CI que diz "green" mas não verifica o artefato que produz.
A pergunta que aprendi a fazer sobre qualquer processo automatizado: "quando foi a última vez que você testou o que acontece quando esse processo precisa ser usado de verdade?"
Essa semana: tem algum processo de backup, restore, ou rollback no seu sistema que você assume que funciona mas nunca testou?