Backup só existe depois que você restaurou

A pergunta "vocês têm backup?" quase sempre recebe um sim. A pergunta seguinte — "quando foi a última vez que vocês restauraram um?" — quase sempre recebe silêncio. Inclusive quando quem pergunta somos nós, olhando para a nossa própria infraestrutura.

Numa revisão dos nossos sistemas, encontramos um banco de produção sem nenhuma cópia fora do fornecedor e uma chave de cifra que não estava em backup nenhum. Nos dois casos, a frase até então era a mesma: "tem backup".

As três perguntas

Hoje todo sistema que colocamos no ar responde a três perguntas antes de receber cliente pagante. Onde está a cópia? Ela precisa estar fora do fornecedor do banco, porque o cenário que mais assusta é justamente perder o acesso à conta. Ela está completa? Conferimos o conteúdo do arquivo, não o tamanho. Eu consigo abrir? A chave de cifra, quando existe, também tem cópia — sem ela, o backup é inútil.

Conferido, não presumido

No sistema de gestão que fazemos para pet centers, por exemplo, o backup é cifrado e enviado para armazenamento em nuvem, e só conta como feito depois que a assinatura do arquivo enviado bate com a do arquivo gerado. O dono do pet center ainda pode baixar uma cópia para um pen-drive, e essa cópia passa pela mesma conferência.

Para bancos de dados, o dump diário é aberto e listado antes de ser aceito. Se a listagem falha, o arquivo é marcado como inválido e as cópias antigas não são apagadas. É uma regra simples que impede o pior cenário: a rotina de limpeza apagar a última cópia boa porque a nova "rodou".

O teste que ninguém faz

Uma vez por mês, vale restaurar um backup num banco vazio e abrir o sistema contra ele. Leva uma hora. É a única forma de saber que a cópia serve — e de descobrir, com calma, o que falta: uma permissão que não veio junto, um gatilho que não foi copiado, um arquivo de mídia que estava em outro lugar.

Cópia que "bate na contagem" pode não ter as permissões nem as regras do banco original. Só a restauração completa mostra isso.