Uma tarefa de backup que termina sem erros e um backup a partir do qual consegue realmente restaurar não são a mesma coisa. Já vimos software de backup reportar sucesso durante meses enquanto o processo de restauro estava, silenciosamente, avariado — uma alteração de permissões, um catálogo corrompido, uma política de retenção que deixou de incluir, sem aviso, uma base de dados crítica. A única forma de saber se o seu backup funciona é restaurar a partir dele, de forma calendarizada, antes de precisar dele a sério.
Como é um verdadeiro teste de recuperação
Um teste a sério não é assinalar uma caixa a dizer que a tarefa foi executada. Significa escolher um sistema — de preferência alternando entre os sistemas críticos de acordo com um calendário, em vez de testar sempre o mais fácil — e restaurá-lo efetivamente num ambiente isolado. Nos backups ao nível de ficheiros, isso significa confirmar que os ficheiros abrem e estão atualizados. Nos backups de máquinas virtuais completas ou de bases de dados, significa arrancar de facto o sistema restaurado e validar que funciona, e não apenas que o processo de restauro terminou.
A cadência trimestral que seguimos
Testamos em rotação trimestral: em cada trimestre, um sistema crítico é alvo de um teste de restauro completo num ambiente isolado, com os resultados registados — o que funcionou, o que não funcionou e quanto tempo demorou. Uma vez por ano, fazemos um teste mais abrangente que exercita de ponta a ponta todo o processo de failover de recuperação de desastres, e não apenas o restauro de um sistema. Esta cadência deteta desvios de configuração antes de se tornarem uma crise, uma vez que a infraestrutura muda constantemente e um plano de recuperação que não é testado novamente após essas mudanças deixa, discretamente, de corresponder ao ambiente que deveria proteger.
O que fazer quando um teste falha
Um teste falhado é um bom resultado, não um mau — significa que encontrou a falha durante um exercício planeado e não durante uma interrupção real. A resposta é a mesma em qualquer caso: documentar exatamente o que falhou, corrigir a causa de fundo (e não apenas o sintoma) e voltar a testar antes de dar o problema por resolvido. Uma estratégia de backup que nunca falhou um teste não foi necessariamente testada com rigor suficiente.