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.

O que falhou e como soubemos

Os logs agora contavam a mesma história. O MariaDB começou a relatar erros de checksum de página do InnoDB, seguidos por falhas de tabelas nas tabelas de pedidos e sessões com muita gravação. O próprio hypervisor estava saudável. O comportamento de CPU, RAM e rede permaneceu normal. Isso afastou o evento de uma indisponibilidade ampla da plataforma e o aproximou da integridade de armazenamento no nível do guest.

Verificamos três coisas antes de tocar nos backups. Primeiro, se o problema estava isolado a um pequeno conjunto de tabelas e podia ser reparado no local. Segundo, se os backups recentes eram válidos e podiam ser montados. Terceiro, se quaisquer transações concluídas após o último backup comprovadamente bom poderiam ser reconstruídas a partir de logs da aplicação, confirmações por e-mail ou registros do gateway de pagamento.

Essa terceira verificação costuma ser ignorada. Não deveria. Restaurar um backup não é toda a recuperação. As empresas se importam com pedidos ausentes, registros de clientes e estado de faturas, não apenas com o fato de o MySQL voltar a iniciar.

O caminho de recuperação que escolhemos

Este estudo de caso de recuperação de backup é útil porque a opção óbvia não era a melhor opção. Tínhamos três caminhos candidatos.

Um rollback completo de snapshot de VM teria sido o mais rápido em termos de quantidade de cliques, mas também descartaria várias horas de mudanças legítimas de conteúdo, atualizações de plugins e edições em contas de clientes. Reparar as tabelas no local trazia risco demais porque a corrupção já havia atingido dados transacionais centrais. O caminho melhor era uma restauração em nível de arquivo e de banco de dados em uma instância nova, seguida por reconciliação seletiva de dados.

Então provisionamos primeiro um ambiente de recuperação limpo. Mesmo tamanho de VPS, mesma família de SO, mesma versão do painel, mesma ramificação de PHP. Reconstruir em uma instância paralela dá espaço para respirar. Também protege o sistema original para revisão forense, o que é útil se o cliente precisar entender a causa raiz ou verificar que o problema não foi causado pelo comportamento da aplicação.

Extraímos o último backup automático bem-sucedido de 23:00 UTC. Depois o testamos antes da troca. Isso parece básico, mas muitas equipes só descobrem problemas no backup na pior hora possível. O arquivo foi montado corretamente, os checksums corresponderam, a importação do banco de dados foi concluída sem erros e a aplicação subiu de forma isolada. Bom. A calma começa aí.

Restaurando o serviço sem criar novos problemas

A recuperação teve quatro etapas. Primeiro, infraestrutura. Reconstruímos a stack web, aplicamos atualizações de sistema que já estavam aprovadas e igualamos as versões de runtime para que a aplicação não falhasse por causa de uma incompatibilidade surpresa de dependências.

Segundo, dados. A restauração do banco de dados foi concluída em 11 minutos. Os arquivos web foram restaurados em menos de 4 minutos. Os assets de mídia estavam intactos, o que poupou o cliente de imagens de produto quebradas e caixas irritadas do navegador. O Redis não foi restaurado a partir do backup porque os dados em cache são descartáveis por definição. Trazer cache obsoleto de volta para um ambiente novo é um daqueles pequenos erros que depois viram uma grande bagunça.

Terceiro, validação. Verificamos login da aplicação, fluxo de checkout, gravações no admin, execução de cron, validade de SSL, e-mail de saída e comportamento de callback do gateway de pagamento. Também comparamos as contagens de registros em tabelas de pedidos, clientes e catálogo com as curvas de crescimento esperadas da semana anterior. Os números não precisam ser poesia perfeita, mas não devem parecer estranhos.

Quarto, reconciliação. Entre 23:00 UTC e 02:14 UTC, um punhado de pagamentos bem-sucedidos havia sido processado. Esses registros não existiam no banco de dados restaurado porque aconteceram após o ponto do backup. Nós os reconstruímos a partir de confirmações do provedor de pagamento, notificações de pedido por e-mail e logs de acesso web. É aqui que um operador experiente evita muita dor de negócio. Uma restauração tecnicamente bem-sucedida que perde pedidos pagos não é realmente um sucesso.

Às 03:41 UTC, a aplicação estava disponível para revisão interna do cliente. Às 04:06 UTC, o DNS e o roteamento de edge redirecionaram o tráfego de produção de volta para a instância recuperada. A interrupção total do checkout visível para o cliente foi de pouco menos de duas horas, enquanto o acesso de leitura à maior parte do site permaneceu disponível durante boa parte do incidente.

O que tornou a recuperação rápida

Não foi sorte, e não foi um único botão mágico de backup. A velocidade veio da preparação e da redução de decisões durante o incidente.

O cliente já tinha backups agendados automáticos com retenção, comportamento do servidor monitorado e um caminho de suporte que não desaparecia no silêncio dos tickets. Isso mudou o formato da noite. Não estávamos debatendo se existia um backup. Estávamos escolhendo o ponto de restauração mais seguro e validando-o.

A consistência do ambiente também importou. Como a stack de hospedagem era padronizada, não passamos 45 minutos nervosos descobrindo que a aplicação restaurada queria uma extensão antiga de PHP ou uma biblioteca de sistema ausente. As pessoas muitas vezes subestimam quanto tempo de recuperação é consumido pelo desvio de configuração.

Houve também um ganho menos visível - separar o que tem estado do que é descartável. Conteúdo do banco de dados, mídia enviada, configuração e assets de SSL foram tratados com cuidado. Cache, arquivos temporários e sessões geradas foram reconstruídos de forma limpa. Isso mantém a recuperação enxuta e evita levar ruído antigo para uma nova inicialização.

O que este estudo de caso de recuperação de backup ensina

A principal lição não é simplesmente fazer backup do seu servidor. A maioria das empresas já conhece essa frase. A lição mais difícil é projetar a recuperação em torno da função de negócio, não apenas de objetos de infraestrutura.

Um snapshot de VM é útil, mas pode ser bruto demais. Um dump de banco de dados é útil, mas não suficiente se os arquivos enviados estiverem separados. Um backup de painel de controle é conveniente, mas a conveniência ainda deve ser testada. A estratégia de backup correta depende de como a aplicação se comporta, com que frequência os dados mudam e qual quantidade de perda é realmente aceitável.

Para um site de e-commerce, imagens de produto geralmente podem tolerar pontos de recuperação um pouco mais antigos do que registros de pedidos. Para uma aplicação SaaS, o estado do banco de dados do cliente pode importar mais do que o conteúdo do filesystem local. Para uma agência digital que hospeda vários sites de clientes em um único servidor, o isolamento se torna crítico porque um site barulhento não deve transformar a recuperação em uma dor de cabeça do rack inteiro.

Os testes também merecem mais respeito. Backups são promessas até serem restaurados. Depois de restaurados, tornam-se evidência. A diferença é cara.

O que mudou após o incidente

Não tratamos a recuperação como a linha de chegada. Após a estabilização do serviço, revisamos o comportamento do armazenamento, a saúde do filesystem, as verificações de integridade do banco de dados e o momento da política de backup. A causa técnica imediata apontou para inconsistência de disco no nível do guest sob pressão de gravação, mas a questão mais ampla era como reduzir o raio de impacto da próxima vez.

A frequência de backup foi ajustada para a camada de banco de dados para encurtar a exposição do ponto de recuperação durante campanhas. Os limites de alerta para espera de I/O e padrões de erro do banco de dados foram endurecidos. O cliente também passou de uma mentalidade de restauração única para uma mentalidade em camadas - backups automáticos, rotinas de restauração verificadas e tratamento mais claro para reconciliação transacional.

É aqui que o suporte operacional gerenciado mostra seu valor. Não porque incidentes nunca aconteçam, mas porque, quando acontecem, alguém já sabe onde olhar primeiro e o que não quebrar enquanto corrige. Essa pequena diferença muitas vezes é toda a diferença.

Se você está executando workloads geradoras de receita, a pergunta útil não é se você tem backups. A pergunta útil é se, às 2 da manhã, você consegue restaurar os dados certos no lugar certo, verificá-los rapidamente e contabilizar o que aconteceu depois que o backup foi feito. Se a resposta for incerta, o sistema ainda está pedindo atenção. Melhor responder isso em uma tarde tranquila do que durante uma falha no checkout.

Andres Saar Engenheiro de Atendimento ao Cliente