Disaster recovery: o que aprendi sobre recuperação de desastres em TI
Fique a conhecer todos os pormenores da recuperação de uma falha grave nos servidores onde o Teamlyzer está alojado.
No dia 27 de Setembro, pelas 9 da manhã, tal como em todos os dias da semana, sento-me em frente ao computador. Abro o email e reparo num aviso da ferramenta de analytics (Yandex metrika). Esta dizia que o Teamlyzer não estava acessível. Ora bem, vamos lá investigar.
Abro o painel de controlo da VPS e as duas máquinas estão desligadas. Ambas estavam na mesma zona, e pelos vistos na mesma infraestrutura física, e como tal ambas foram afetadas por uma falha no Raid.
Até aqui tudo bem, o pior é esta falha levou a que os discos virtuais ficassem completamente inutilizados. Ou seja, as duas máquinas ficaram limpas, sem sistema sequer.
Depois de falar com o suporte da Iwstack fiquei a saber que os discos estavam limpos, zero, rien, e que a recuperação de dados tinha tido uma taxa de sucesso de 0%.
Por volta das 11 horas já tinha percebido que não restava nada das máquinas de produção, próximo passo era verificar se os meus backups tinham funcionado.
O backup da base de dados funcionou de forma correta e apenas houve um delay de 3 horas desde o último backup.
Deste logo ficou garantida uma versão praticamente up-to-date. Por sua, vez dados pouco relevantes, como as notificações, que funcionam primeiramente em memória, foram limpos.
Vamos por pontos:
#1 - Ter ferramenta de monitorização da disponibilidade do sistema
É fundamental ter algum mecanismo que faço a monitorização das máquinas, para assim que haja um problema, sabermos. No meu caso foi o Yandex metrika, e funcionou perfeitamente.
#2 - Ter ferramentas de backups próprias
Desconfiar do sistema de backups de terceiros. Ou seja, a ferramenta de recuperação do Iwstack falhou completamente, levando a uma perda total de base de dados, filesystem e código em produção de todos os projetos na mesma infraestrutura.
Também tenho a minha quota-parte de responsabilidade porque devia ter uma cópia permanentemente atualizada do disco da máquina.
O que parecia impensável, ou seja, ter as duas máquinas afetadas, que eram “espelho” uma da outra, e com os sistemas corrompidos, exatamente ao mesmo tempo, aconteceu.
Já me tinha acontecido ter base de dados corrompidas por shutdown à bruta, problemas com diretorias, etc, agora ficar com os discos limpos foi a primeira vez... Ransomware ao pé disto é para meninos :)
#3 - Ter código de desenvolvimento igual ao de produção
É fundamental ter o código de desenvolvimento presente no Trunk igual ao de produção.
Desta forma o redeploy é bastante simples de fazer. É aqui que também entra a importância de ter uma ferramenta de versionamento de código.
#4 - Trabalhar com ferramentas que dominamos
Talvez seja o fator mais relevante. É essencial ter conhecimentos sobre aquilo que estamos a usar, para podermos agir imediatamente, sem dependermos de suporte de terceiros ou ainda da sua boa vontade.
Neste caso foi meter as mãos na massa e ver o copo meio cheio. Aproveitei para fazer upgrades ao sistema, e deixar o Teamlyzer ainda mais rápido e seguro. Upgrade para Debian 9, nginx, page speed, passamos ainda a usar HTTP2. Postgres e Redis sofreram também eles upgrades.
#5 - Balanço final
Resumindo, não houve perdas de dados relevantes, que era o mais importante. A partir do momento em que percebi a dimensão do problema o próximo passo foi estruturar um plano de ação, ponto por ponto, sobre o que tinha de fazer.
Estamos de volta, e agora mais preparados.