Backup que funciona de verdade: como testar

Backup só passa a existir no momento em que alguém consegue restaurá-lo. Antes disso, é uma suposição com nome bonito. A maioria das empresas que perde dados tinha backup, o que faltava era saber se ele estava íntegro, se cobria tudo e quanto tempo levaria para voltar. Este texto trata dessas três perguntas.

A regra 3-2-1, e por que ela ainda vale

Três cópias dos dados, em dois tipos de mídia ou provedores diferentes, com uma delas fora do local principal. É antigo e continua sendo o piso.

Traduzido para um sistema web típico:

• Cópia 1: o banco de dados em produção.
• Cópia 2: dump automático diário guardado em armazenamento de objetos do mesmo provedor.
• Cópia 3: o mesmo dump replicado para outro provedor ou para um disco fora da nuvem.

A terceira cópia é a que salva nos cenários que ninguém quer imaginar: conta suspensa por engano, credencial vazada com exclusão em massa, ransomware que criptografou o servidor e os discos montados nele.

Uma extensão moderna da regra acrescenta uma cópia imutável, armazenamento com bloqueio de objeto, em que nem uma credencial de administrador consegue apagar antes do prazo. Contra ransomware, é a única coisa que funciona de forma confiável.

Defina RPO e RTO antes de escolher a ferramenta

Dois números decidem toda a arquitetura:

RPO (Recovery Point Objective): quanto dado a empresa aceita perder. Backup diário às 3h significa que uma falha às 22h perde 19 horas de trabalho.

RTO (Recovery Time Objective): quanto tempo o sistema pode ficar indisponível.

Levantar esses números com quem responde pela operação evita as duas pontas do erro: pagar por replicação contínua num sistema que aceita perder um dia, ou descobrir na crise que o dump semanal custou uma semana de faturamento.

O que fazer backup, além do banco

Restaurar só o banco quase nunca coloca o sistema de volta. Faltam:

• Arquivos enviados por usuários, contratos, fotos, anexos. Muitas vezes ficam em disco ou armazenamento de objetos, fora do dump.
• Variáveis de ambiente e segredos. Chaves de API, credenciais de integração, certificados. Guarde num cofre com backup próprio.
• Configuração de infraestrutura. Proxy reverso, regras de firewall, agendamentos, DNS.
• Código e migrações do banco. Se o repositório vive num único serviço, tenha um espelho.

Escreva a lista e confira contra o que a rotina de backup realmente cobre hoje. É comum descobrir que os anexos nunca entraram.

Backup lógico e físico: use os dois

Dump lógico (pg_dump, mysqldump) gera um arquivo portátil, que restaura em outra versão e em outro provedor. É lento para bancos grandes, mas é o que garante independência.

Snapshot ou backup físico copia o estado do disco ou dos arquivos do banco. É rápido para restaurar, mas amarrado à mesma versão e, muitas vezes, ao mesmo provedor.

PITR (point-in-time recovery) guarda o log de transações continuamente e permite voltar o banco a um minuto específico. É o que resolve o caso mais comum de perda de dados: não o servidor que morreu, mas o DELETE sem WHERE que alguém rodou às 15h47.

O roteiro de teste de restauração

Este é o item que separa quem tem backup de quem acha que tem. Faça assim, com cronômetro:

1. Escolha um backup real, de preferência de alguns dias atrás, não o de hoje.
2. Suba uma máquina limpa, sem nenhum resquício do ambiente de produção.
3. Restaure o banco a partir do arquivo, anotando o horário de início e de fim.
4. Restaure os arquivos de usuário e os segredos.
5. Suba a aplicação apontando para o banco restaurado.
6. Valide com casos concretos: faça login, abra os cinco relatórios mais usados, confira o total de registros das tabelas principais contra produção, abra um anexo antigo.
7. Anote o tempo total. Esse é o seu RTO real, não o que estava no plano.
8. Registre a data e quem fez. Se não está registrado, não aconteceu.
9. Destrua o ambiente de teste, ele contém dado de produção e vira risco se ficar de pé.

Quase todo primeiro teste falha em algo: falta um arquivo, uma extensão do banco não estava instalada, uma variável de ambiente estava só na cabeça de alguém. É exatamente para isso que se testa antes da crise.

Monitorar o backup, não só executá-lo

Rotina de backup falha em silêncio. O disco enche, a credencial expira, o cron para. Três verificações automáticas evitam a maioria dos casos:

• Alerta de ausência. Se não chegou backup novo em 26 horas, alguém precisa ser avisado. É mais confiável alertar pela falta do que pelo erro.
• Verificação de tamanho. Um arquivo 90% menor que o de ontem indica dump interrompido.
• Restauração automática de amostra. Uma vez por semana, restaure em ambiente descartável e rode uma contagem de registros. É o teste que roda sozinho.

Retenção: quantas cópias guardar

Um esquema que funciona para a maioria dos casos:

• Diários dos últimos 14 dias
• Semanais das últimas 8 semanas
• Mensais dos últimos 12 meses
• Anuais conforme obrigação fiscal e contábil

Backup contém dado pessoal e entra nas mesmas regras de retenção da LGPD, guardar cópia indefinidamente sem justificativa é um problema, não uma precaução. Alinhe o prazo de guarda com a política de retenção do sistema e valide os prazos legais com o contador e o jurídico.

Se hoje você não sabe dizer a data da última restauração bem-sucedida, esse é o próximo item da lista, antes de qualquer melhoria no sistema.