Backup que nunca foi restaurado não é backup

Existe uma categoria de trabalho que ninguém elogia e todo mundo sente falta no pior dia possível. É a camada que decide se o seu produto fica de pé.

Cinco perguntas separam quem tem infraestrutura de quem tem sorte.

1. Quando foi a última vez que você restaurou um backup?

Não "quando foi o último backup" — quando foi a última restauração. Backup que nunca voltou é uma hipótese, não uma garantia. Arquivo corrompido, rotina que parou de rodar em silêncio há três meses, dump sem uma tabela: tudo isso só aparece na hora de restaurar.

Faça o teste hoje. Restaure em um ambiente separado e confira se o dado está lá.

2. Quanto tempo você aguenta fora do ar?

Essa resposta define quanto vale investir. Uma hora fora do ar em um site institucional é um aborrecimento. Uma hora em um sistema de agendamento clínico é um dia de operação perdido, telefone tocando e paciente remarcando.

Quem sabe esse número decide com clareza o que precisa de redundância e o que não precisa.

3. Como você descobre que caiu?

Se a resposta é "o cliente avisa", não existe monitoramento. O básico resolve a maior parte: verificação de saúde a cada minuto, alerta em um canal que alguém realmente lê, e um registro de erros com contexto suficiente para diagnosticar sem adivinhação.

4. Quem tem acesso ao banco de produção?

Provavelmente mais gente do que deveria, com credencial que nunca expirou, em um arquivo que já passou por WhatsApp. Acesso a produção precisa ser nominal, revogável e registrado. E chave de serviço nunca deve estar em código que vai para o navegador — ela vive no servidor, e só.

5. Dá para voltar a versão anterior em um comando?

Deploy sem rollback é aposta. Se a versão nova quebrou às 18h de uma sexta, a pergunta não é "como conserto", é "como volto para o que funcionava" — e depois conserto com calma.

Por que isso aparece na proposta

Cliente às vezes estranha ver ambiente de homologação, pipeline de publicação, backup e monitoramento em um orçamento de sistema. É justo estranhar: nada disso aparece na tela.

Mas é o que separa software que roda de software que sustenta um negócio. Colocar depois custa três vezes mais — porque agora tem dado real dentro, gente dependendo, e nenhuma janela confortável para mexer.

Como fazer um teste de restauração em uma tarde

Não precisa de equipe nem de ferramenta cara. O roteiro cabe em uma tarde:

1. Escolha o backup mais recente e anote a data e o tamanho. Backup de poucos kilobytes para um banco que tem anos de uso é sinal de problema.
2. Crie um ambiente separado, sem nenhuma ligação com a produção: um banco novo, um servidor de teste, até o computador de quem está fazendo o teste.
3. Restaure e cronometre. Esse tempo é o dado mais importante: é o quanto você realmente leva para voltar ao ar.
4. Confira o conteúdo. Conte registros de três ou quatro tabelas importantes, abra alguns cadastros reais, confira se as imagens e os anexos estão lá. Um backup pode restaurar "com sucesso" e vir incompleto.
5. Registre o resultado em um documento curto: data, quanto demorou, o que faltou, quem fez. Repita a cada trimestre ou depois de qualquer mudança grande no sistema.

RPO e RTO, sem jargão

Dois números orientam toda a conversa sobre recuperação:

• RPO (quanto dado você aceita perder): se o último backup foi ontem à noite e o sistema caiu hoje às 17h, você perdeu um dia de trabalho. Uma clínica que agenda dezenas de consultas por dia dificilmente aceita isso; um site institucional, sim.
• RTO (quanto tempo você aceita ficar fora): é o tempo entre a queda e a volta. O teste de restauração mostra o seu RTO real, não o que você imagina.

Quando o negócio define esses dois números, a infraestrutura deixa de ser opinião e vira decisão com custo claro.

Onde guardar as cópias

Uma regra simples e antiga ainda funciona bem, a 3-2-1: três cópias dos dados, em dois tipos diferentes de armazenamento, com uma delas fora do local principal. Na prática, isso quer dizer que o backup não pode morar no mesmo servidor do sistema, nem na mesma conta que um invasor ou um erro humano consegue apagar de uma vez. Cópia que some junto com o original não é cópia.

Checklist rápido para hoje

• Existe backup automático ligado e alguém recebe aviso quando ele falha?
• O backup fica em outro lugar, com acesso separado?
• A restauração foi testada nos últimos três meses?
• Há um documento dizendo quem faz o quê numa emergência?
• Você sabe o tempo de recuperação em horas, não em palpite?

Se duas ou mais respostas forem "não", o risco é real e a correção é barata perto do custo de um dia sem sistema.