Um relato de quem estava lá!
- e com relógios precisos -
Num tempo remoto, mas não muito, o
estudiolivre.org sofreu um
ataque de
crackers russos. Uma das principais causas da falha foi o fato do banco de dados
MySQL não ter uma senha. De qualquer forma, o ataque acontecendo ou não, isso foi diagnosticado como uma falha de segurança. Obviamente uma senha foi introduzida e nenhuma perda maior foi percebida. Além disso, percebeu-se que os
backups feitos a cada dia não eram suficientes para repor perdas caso elas viessem a acontecer (como mostrava-se possível naquele momento). A solução: mais
backups! Para isso foi criado um esquema paralelo aos
backups diários, seriam feitos
backups do banco a cada 2 horas através de
dumps!
Depois... No dia 13/09 os integrantes do
HackLab de São Paulo encontravam-se em Brasília para uma imersão com os desenvolvedores do MinC. Na manhã desse dia
um email aparece na lista. Nele há um relato de um bug na interface do Conversê, não só um bug, como as conseqüências maléficas do mesmo: as
10:34:10 todos os comentários feitos no
converse.org foram apagados. Mas sabíamos que tínhamos muitos backups, então não havia o que temer. Para que nada mais acontecesse, o
site fica fora do ar a partir das 11h. Logo constata-se que nem havia necessidade de manter o site fora do ar para restaurar os comentários: ele volta ao ar uma hora depois de ter saido. As
12:43:46 começa a 'recuperação' dos comentários: um
backup antigo do banco é restaurado. Por precaução, o
backup é restaurado apenas no ambiente de testes do
converse.org e a restauração é verificada. Mas algo não parece bem. As informações não estão corretas, faltam algumas coisas. Duas novas tentativas de restauração foram feitas, sem sucesso. Aí começa a confusão....
Dois relatos de problemas aparecem logo nesse momento: através da lista do estudiolivre o glerm reclama que algumas páginas sumiram. Através do
gChat o Alex reporta que Felipe Santos perdeu algumas coisas que estava fazendo no mapsys.
Nesse meio tempo descobre-se que houve uma falha de
backup, aparentemente, só havia
backups até o dia 01/09. Foi restaurado esse último
backup para recuperar tudo o que fosse possível.
A restauração, na verdade, havia
triturado os bancos de dados. Todos os bancos! Desde o primeiro momento em que ela ocorre, todos os bancos 'voltam' no tempo para o dia
15/08 as 14:31; ou seja, o backup não é tão novo quanto se esperava e, pior, ele não é só do banco do
converse.org e muito menos está sendo aplicada só no ambiente de testes desse último, todos os outros sistemas são afetados (mapsys e estudiolivre).
Logo que isso é detectado, as
14:09:29, todos os sistemas saem do ar. É um momento delicado. O servidor é reconfigurado para não responder a requisições
TCP, ou seja, ele sai do ar mesmo! É só as
17:37:05 que o servidor volta a responder e mostra uma mensagem dizendo que os sistemas estão em manutenção.
Começa uma busca para entender o que havia acontecido. Descobre-se que o último backup disponível tinha sido feito há quase um mês. Não há outros backups. Outros backups que poderiam estar nas máquinas dos desenvolvedores dos sistemas começam a ser procurados, eles não são muito mais novos. A alternativa parece ser usar o
cache do google para restaurar as páginas. Essa alternativa não é muito boa, mas parece ser mesmo a única saída. Começam os trabalhos para colocá-la em prática.
Mas eis que surge a última luz: logs binários, feitos automaticamente, sem que os desenvolvedores e administradores soubessem do que se tratava, são encontrados no servidor. Aparentemente têm todas, absolutamente todas, as informações de todas as transações feitas no banco. São 33Gb de dados. Mal há espaço no HD do servidor para lidar com tudo isso. Começa uma operação delicada de transferências de dados. Horas e horas são gastas transferindo dezenas de gigabytes. Onze gigabytes são 'separados' e tratados com mais cuidado. São os dados cruciais do mês 'perdido'. O espaço livre no HD no servidor começa a ficar cada menor. Ao final inicia-se a restauração em si, o processo é lento, muito lento. São aproximadamente 6.8Gb de instruções que precisam ser repetidas no banco. No total são gastas 7 horas, 31 minutos e 17 segundos na noite de quarta para quinta para que os dados sejam completamente restaurados. Mais de 48Gb de dados são gerados em todo o processo.
No dia 14/09 as
8:35:40 os sistemas voltam ao ar. Aparentemente os dados estão lá. Todos eles. Mas não é tão simples... Um fantasma antigo volta a assombrar: a incompatibilidade dos caracteres especiais com o MySQL. Esse problema já havia sido corrigido no passado (alguém lembra do "Á"?); mas não da forma mais indicada. Uma solução através da forma mais indicada já fora pesquisada, mas depois de mais de 7 horas gastas nessa tentativa ela foi abandonada. Mesmo assim ela vai ter que surgir nos próximos dias. As páginas todas estão lá nos backups, logs binários, dumps, em algum lugar! E elas vão voltar. Elas sempre voltam.
O que aconteceu com o backup não se sabe ao certo. Há três hipósteses para explicar os problemas enfrentados: especula-se que a linha no crontab que faz backup possa ter sido comentada acidentalmente no dia 01/09. No entanto, independente disto ter acontecido, o backup pode ter parado de ser feito no dia 15, ou seja, quando colocou-se a senha no banco de dados. Mesmo assim a parada da criação dos backups aparentemente ocorreu um dia antes da criação das senhas. Ou seja, algum desses fatores ou uma combinação deles, levou a parada da criação de backups como se esperava.
Situação atual: a razão pela qual algumas páginas foram perdidas é conhecida. Trata-se de uma falha de encoding do dump do banco de dados, que foi escolhida como única forma de backup do banco, o backup gerado é corrompido e gera erros ao ser importado. A criação de dumps consistentes já foi implementada, porém o último backup feito ainda está com esse problema. Maneiras de restaurar um backup mais antigo de forma consistente e reconstruí-lo novamente em outra máquina estão sendo pesquisadas. Outra alternativa é tratar automaticamente o backup com problemas para pelo menos não gerar erros de importação, mesmo que para isso as páginas importadas fiquem com alguns caracteres estranhos (pelo menos não se perde a página inteira).
FIM
