"Temos backup"
Todos os produtos tinham backup. Havia CronJobs que geravam dumps dos bancos e mandavam para um bucket, e isso bastava para a pergunta "vocês têm backup?". Mas ninguém sabia responder as perguntas que importam num desastre: o backup restaura? Quanto tempo leva para voltar? Quantos dados podemos perder? E se o backup parar de funcionar, alguém fica sabendo?
A única forma honesta de responder era restaurar.
Restaurar de verdade
Provisionei um ambiente de restore isolado e, logo no começo, encontrei uma falha no Terraform: o disco de dados de 600 GB nunca era formatado nem montado. Corrigi, isolei o disco de um outro teste que rodava em paralelo, e fiz o restore do banco de produção por streaming, direto do bucket, sem passar por nenhuma máquina local. Foram 249 GB e 85 tabelas em 2h41, com a integridade validada.
O exercício revelou o que nenhum painel mostrava. Os backups de produção estavam falhando fazia mais de um dia, em silêncio. Havia uma inconsistência de integridade referencial que já existia em produção e teria passado despercebida. E o bucket acumulava cerca de 92 TB sem política de ciclo de vida, uns US$ 2,3 mil por mês.
Repeti o método num produto com MongoDB. O dump saiu de um nó secundário, fora do horário de pico, com atraso de replicação máximo de 15 segundos e sem impacto em produção. Foram 425 milhões de mensagens restauradas sem nenhuma falha, com checksum idêntico. O tempo de recuperação medido foi de cerca de 5h20, porque reconstruir os índices levou mais tempo que carregar os dados.
Por que o backup falhava
A rotina de retenção tinha um deadlock: os dumps antigos só eram apagados depois de um backup bem-sucedido. Quando o disco enchia, o backup falhava antes de limpar, e o ciclo nunca se recuperava sozinho. O volume chegou a 96%, cheio de dumps parciais. Liberei espaço apagando só cópias que eu já tinha validado no bucket e corrigi a causa: o dump passou a ir direto para o bucket, sem guardar cópia local.
Num terceiro produto, encontrei uma falha silenciosa antes que ela acontecesse. O job de backup não tinha tempo máximo de execução, não permitia execução concorrente e mandava a notificação de dentro dele mesmo. Um job travado bloquearia todos os backups seguintes, e o aviso dependeria justamente da coisa que tinha travado. Propus detectar a falha de fora, pela idade do último sucesso.
Fazer o backup avisar, e protegê-lo
Criei alertas de falha e de backup parado há mais tempo que o esperado, além de avisos de início, sucesso e falha no canal do time. Validei as regras com promtool antes de aplicar.
O dump também subia em texto legível: um vazamento do bucket exporia o banco inteiro, com dados pessoais. Avaliei três formas de guardar as chaves e escolhi envelope encryption com o KMS da nuvem, com uma chave de dados nova por arquivo, a chave mestra que nunca sai do KMS e verificação de integridade por HMAC. O custo adicional foi zero. Separei os privilégios em duas identidades: uma que só cifra e escreve, outra que só decifra e lê. A credencial do bucket saiu de um ConfigMap para um Secret, e os manifestos que só existiam no cluster foram para o Git, conferidos campo a campo com produção.
Transformar em política
Com os tempos medidos em mãos, escrevi a política de recuperação de desastres, com metas de RPO e RTO baseadas no que de fato aconteceu nos testes, registro dos ensaios, frequência e critérios de sucesso, alinhada aos controles de backup e continuidade da ISO 27001. Para que a confiança não dependesse de alguém lembrar de testar, criei um drill automático: um job que pega o backup cifrado mais recente, decifra, restaura num banco de teste, valida e avisa o time.
No caminho, encontrei e documentei um banco de produção que não tinha backup nenhum, com o plano para implantá-lo.
O que mudou
Os backups dos produtos principais deixaram de "existir" e passaram a ser restaurados e medidos. RTO e RPO viraram números de uma política, e não estimativas. Os backups que falhavam em silêncio passaram a avisar o time, e os dumps passaram a ser cifrados, com chaves fora do alcance de quem só tem acesso ao bucket.
O que eu levo disso
A única forma de saber se um backup funciona é restaurar. Cada teste revelou algo que nenhum dashboard mostrava. E o tempo real de recuperação (5h20, e não "umas duas horas") só aparece quando você mede.