Estudo de Caso de Recuperação de Backup: 6 Horas Antes
Publicado em 10 de julho de 2026
Às 02:14 UTC, a loja virtual parou de gravar pedidos no banco de dados. Às 02:19, o site ainda servia páginas em cache, mas o checkout já tinha se tornado ficção. Este estudo de caso de recuperação de backup acompanha o que aconteceu em seguida em um VPS de produção para um pequeno negócio de e-commerce, o que restauramos, o que não restauramos às cegas e por que o serviço voltou a ficar estável antes do amanhecer.
O cliente executava uma stack bastante padrão para uma loja virtual em crescimento - Nginx, PHP-FPM, MariaDB, Redis e um painel de controle usado por dois funcionários que não eram sysadmins. O tráfego não era enorme, mas o momento foi doloroso. Uma campanha de vendas havia aumentado o volume de pedidos, as gravações no banco de dados estavam no pico e um problema de armazenamento na camada do filesystem começou a corromper tabelas ativas do banco de dados. Nada dramático no estilo de Hollywood, mas sério o suficiente para que cada minuto importasse.
A primeira tarefa não era a restauração. A primeira tarefa era impedir que o dano se espalhasse. Colocamos a aplicação em modo de manutenção, preservamos o estado atual do disco para revisão e verificamos se replicação, snapshots ou dumps lógicos nos dariam o ponto de recuperação mais limpo. Isso importa mais do que as pessoas gostam de admitir. Recuperação rápida é bom. Recuperação rápida para dados danificados é apenas decepção rápida.
