Restaurando banco de dados MySQL deletado do arquivo de log

Question

Ontem à noite eu deletei acidentalmente um banco de dados de produção MySql em uma gota digital do oceano. Eu imediatamente encerro o apache e o MySql. Eu tenho os seguintes arquivos ib *:

• ib_buffer_pool
• ib_logfile0
• ib_logfile1
• ibdata1
• ibtmp1

Existe alguma maneira que eu possa restaurar meu banco de dados a partir desses arquivos? Alguém tem um programa ou sabe de um que pode reconstruir isso? Se não for um programa, uma maneira de representar as últimas alterações no servidor?

Não tenho backup.

    

Answer 1

Não, desculpe. Esses arquivos são do mecanismo de armazenamento innodb e são diários, logs, etc. Embora o registro em diário garanta a consistência dos dados, ele usa apenas metadados para fazer isso - portanto, se você não tiver dados para usar, não estará recuperando nada.

Mas isso talvez não seja tanto um problema quanto parece. A maioria dos sistemas de arquivos é relativamente fácil de recuperar dados de desde que você não escreva de alguma forma . Uma gravação pode substituir seus dados excluídos antigos. Após uma exclusão, um arquivo é simplesmente retirado do "índice do sistema de arquivos", deixando os dados reais para trás (que podem ser sobrescritos com novos dados se você usar o sistema de arquivos).

testdisk é um excelente utilitário para restaurar (excluir arquivos). Existem vários outros que você pode usar, muitos dos quais são específicos do sistema de arquivos. Eles devem ser executados em um dispositivo de bloco desmontado. Portanto, se você deseja recuperar esses dados, pare de usar esse volume imediatamente e abra-o com testdisk ou similar. Você também deve criar uma imagem do dispositivo de bloco subjacente e trabalhar com isso, em vez de operar em seu original. dd é uma ótima utilidade para fazer isso.

Talvez você tenha instantâneos de volume de algum tipo? Isso permitiria que você revertesse essa mudança, potencialmente. Você também pode usá-lo para capturar instantaneamente seu volume em seu estado atual antes de tentar uma recuperação, contornando a necessidade de copiar o dispositivo de bloco inteiro.

    

Answer 2

Antes de tudo, gostaria de observar que a resposta "não" é logicamente falsa. Porque se você não conhece uma solução, isso não significa que ela não existe.

Agora, a questão principal era innodb_file_per_table , ON ou OFF. O padrão nas versões recentes é ON, portanto, muito provavelmente, os dados foram excluídos juntamente com os respectivos arquivos *.ibd . A recuperação bem-sucedida depende muito de quanto tempo você parou de gravar na partição do MySQL. Pegue a imagem da partição o mais rápido possível e trabalhe com a imagem. Eu não recomendo a exclusão de arquivos * .ibd, este método provou render menos dados recuperados. Eu suspeito que o motivo principal é que uma ferramenta de exclusão de arquivos deve reconstruir um arquivo e sacrificar pedaços com dados. Seu objetivo, no entanto, é recuperar os registros, por isso recomendo procurar páginas InnoDB. stream_parser de Undrop for InnoDB (eu sou o autor) faz isso. Veja as instruções passo-a-passo no post do meu blog link

Se innodb_file_per_table estava OFF, o trabalho é mais fácil - todos os dados estão em ibdata1, há menos chance de sobrescrever os dados se você parou o MySQL imediatamente. Siga este post para este caso - link .

Em ambos os casos, você precisará recuperar o esquema. Você pode pegá-lo de backups antigos (se houver), scripts de instalação - qualquer coisa semelhante. Se você não tem nada, o último recurso é recuperar o esquema do dicionário InnoDB. Ele reside em ibdata1 - o post sobre como fazer esse link . Por favor, note - a estrutura deve ser 100% precisa.

No geral, devo admitir que as chances são pequenas, mas se você agir rápido e com um pouco de sorte, poderá recuperar alguns, se não todos os dados.

Então, boa sorte.