Backup que você nunca restaurou é hipótese

Faço a mesma pergunta em toda auditoria: quando foi a última vez que vocês restauraram um backup, num ambiente real, e usaram o resultado? A resposta mais comum é uma pausa. A segunda mais comum é 'a plataforma faz automaticamente'. As duas respostas querem dizer a mesma coisa. O time tem uma hipótese de que consegue recuperar, e nunca testou.

Backup que nunca foi restaurado não é backup. É um arquivo que talvez seja um backup. A diferença só é descoberta no dia em que importa, que é o pior dia possível para descobrir qualquer coisa.

Os jeitos que o restore falha

O backup existe, mas as credenciais para descriptografar foram rotacionadas e a chave velha sumiu. O backup existe, mas é só do banco, e o object storage com os arquivos enviados nunca foi incluído. O backup existe, mas tem quatrocentos gigabytes e restaurar leva onze horas, enquanto o negócio assumiu uma. O backup existe, mas o schema dentro dele está três migrations atrás do código que está em produção agora, e ninguém sabe qual versão do código combina com ele.

O backup existe, mas o procedimento de restore referencia um servidor que foi desligado. O backup existe, mas foi tirado no meio de uma transação com estado inconsistente que o banco se recusa a carregar. O backup existe, mas está silenciosamente vazio há seis semanas porque um cron falhou e ninguém configurou alerta de ausência.

Cada um desses eu já vi, e nenhum sobreviveria a um único restore ensaiado.

Como é um teste de restore de verdade

Pegue o backup mais recente. Restaure num ambiente novo que não tem nada em comum com produção além das versões de software. Suba a aplicação apontando para ele. Faça login. Rode os três fluxos de usuário mais importantes. Compare alguns registros conhecidos com produção. Cronometre a coisa toda. Anote cada passo que alguém precisou improvisar.

Esse último item é o retorno. Os passos improvisados são os que vão ser esquecidos durante o incidente real. Cada um vai para o runbook, e o próximo ensaio deveria ter menos deles. Quando o restore puder ser executado por alguém que não escreveu o runbook, de um notebook limpo, dentro do tempo que o negócio espera, aí você tem um backup.

Dois números que você precisa decidir

Recovery point objective é quanto dado você está disposto a perder, medido em tempo. Se os backups são diários, a resposta é até vinte e quatro horas, e você deveria falar essa frase em voz alta para quem é dono do negócio. Se isso é inaceitável, você precisa de arquivamento contínuo do write-ahead log, ou de replicação, e esses são investimentos diferentes com modos de falha diferentes.

Recovery time objective é quanto tempo o negócio pode ficar fora enquanto você restaura. Esse número é decidido pelo negócio e limitado pela física. Um banco grande não é restaurado de um dump em minutos. Se o objetivo é minutos, a resposta é uma réplica em standby, não um restore mais rápido.

Nenhum dos dois números pode ser escolhido só pela engenharia. Os dois precisam estar escritos, e a estratégia de backup precisa ser checada contra eles, não contra o que a plataforma oferece por padrão.

A disciplina mínima

• Backups cobrem tudo que tem estado: banco, object storage, secrets, configuração e a fila se ela guarda trabalho não processado.
• Um alerta dispara quando um backup não completa, não só quando ele falha com barulho.
• Pelo menos uma cópia mora em outra conta ou outro provedor, com credenciais que uma conta de produção comprometida não alcança.
• Um restore é ensaiado com frequência, trimestral no mínimo, e o tempo medido é comparado com o objetivo.
• O runbook é atualizado depois de cada ensaio, pela pessoa que fez ele.

São algumas horas por trimestre. A alternativa é descobrir, durante uma queda, que aquilo que você pagou todo mês era hipótese desde o começo.