O backup que falhou na hora H: redundância é ter camadas independentes
Um disco avisou que ia falhar, a troca foi adiada e o backup testado todo mês não restaurou. O caso real que mostra por que um backup só é aposta.
Um caso real que eu gosto de contar, porque quase deu muito errado.
Nosso monitoramento proativo avisou: um disco estava começando a falhar num servidor que rodava aplicações críticas de um cliente. Avisamos. E avisamos de novo. A recomendação era simples: trocar e colocar dois discos espelhados (RAID 1), pra que, se um morresse, o outro segurasse a operação.
O cliente foi adiando a compra. Acontece. Enquanto está funcionando, parece que dá pra deixar pra depois.
O disco morreu antes da aprovação. Servidor fora do ar, empresa parada.
Trocamos o hardware e fomos restaurar o backup. E aí veio o susto: a restauração falhou. Mesmo com o backup sendo testado todo mês.
O que salvou o dia foi ter um segundo backup, em outra ferramenta, independente do primeiro. Restauramos por ele e o servidor voltou a operar.
A lição saiu cara, mas ficou clara. Depois do incidente, o cliente aprovou os dois discos em RAID 1, montamos uma réplica do servidor e ainda adicionamos um backup na nuvem.
Hoje, pra derrubar essa operação de vez, teria que falhar tudo ao mesmo tempo.
Dois aprendizados que valem pra qualquer empresa:
- O monitoramento te dá o aviso. Mas o aviso só vira proteção quando alguém decide agir.
- E um backup só é aposta. Redundância de verdade é ter camadas que não dependem uma da outra.
Na sua empresa, se o backup principal falhasse na hora de restaurar, existe um plano B? Ou é ele ou nada?