[Banco de dados] um rm -rf a empresa não eliminar todo o banco de dados

informações sobre o número Yunqi: [ Clique para mais notícia Indústria ]
onde você pode encontrar informações diferentes indústrias em primeira mão sobre a nuvem, o que você está esperando, venha!

 

imagem

Experiente dois dias de esforços ininterruptos, finalmente retomou dados do servidor de produção mau uso, uma vez excluído.
O processo do acidente e soluções neste disco, alertar a si mesmo e outros que sugerem Mo cometi este erro.

Espero que os problemas encontrados amigos podem encontrar um traço de inspiração para resolver o problema.

fundo acidente

Organizar uma irmã instalado em um servidor de produção Oracle, instalação lado pesquisa de ponta irmã, a instalação não se sente pronto para reinstalação de desinstalação.

Encontrar desinstalação a partir da Internet, onde a linha de comando a ser executado remover o diretório de instalação do Oracle, o comando é o seguinte:

rm -rf $ORACLE_BASE/*

Se ORACLE_BASE variável não é atribuído, em seguida, o comando passa a ser:

rm -rf /*

E assim por diante, mas minha irmã utilizado conta root ah. Desta forma, todo os arquivos do disco apagado tudo, incluindo a aplicação de Tomcat, banco de dados MySQL e assim por diante ......

banco de dados MySQL não está funcionando? Linux pode excluir o arquivo que está sendo executado? Porque ele é completamente removido e, finalmente, deixou um arquivo Tomcat de Log, estima-se que o arquivo é muito grande, e às vezes não excluído com sucesso.

Observando os olhos irmã remorso, é essa coisa que eu arranjei para ela fazer, não lhe disse as apostas limpar, sem qualquer formação, a responsabilidade só pode ser uma pessoa de volta, e além de como fazê-la bonita urso esta responsabilidade ?

Uma chamada para o quarto, pendurar o disco para outro servidor, vista SSH ascensão todos os arquivos são apagados, esse servidor está em execução, mas o sistema de produção de um cliente, ah, tem funcionado por seis meses, foi restaurado mais rapidamente possível ah.

Em seguida, enviado para o backup offline do banco de dados, localize o arquivo backup somente 1 KB, que fica a apenas algumas linhas de comentário mysqldump familiarizado (script de backup Crontab é executado em questão), o backup mais próximo é em dezembro de 2013 de uma casa realmente gotejante cada ah chuva da noite.

Pense nisso um líder disse que o caso: Quando um sistema de produção de pendurar, encontrar todos os backups tiver dúvidas, DVD também tem riscos, unidades de fita também é ruim (uma indústria sênior, estimativas anteriores também fazer um CD-ROM de backup ), eu não esperava realmente cumprido o meu corpo, como fazer?

Depois que o departamento cabeças ciente da situação, o pior foi feito Plano B: AA e liderança de produto conduziu pessoalmente domingo onde os clientes correram para a cidade segunda-feira a comunicação da liderança; BB e CC ir até lá para encontrar maneiras de administrador do cliente convencer os clientes ......

Straw: ext3grep

Para a Internet para encontrar informações rapidamente ser excluídos por engano de recuperação de dados, encontrar um realmente ext3grep pode recuperar arquivos apagados por rm -rf, nós formato de disco também ext3, e há muitas histórias de sucesso on-line.

Então acendeu uma luz de esperança, o mais cedo possível na umount disco, para evitar re-escritos para fazer eliminado setor arquivos. Baixar ext3grep, instale (compilar e instalar o processo meticuloso, por enquanto, não é a tabela).

Primeiro executar um comando de digitalização nome do arquivo:

ext3grep /dev/vgdata/LogVol00 --dump-names

Imprimir todos os arquivos e caminhos excluídos, regozijando-se, sem a realização de um Plano B, os arquivos estão na mesma.

Este software pode restaurar arquivos por diretório, todos os comandos podem ser executados apenas a recuperação:

ext3grep /dev/vgdata/LogVol00 --restore-all

Os resultados da actual falta de espaço em disco, de maneira nenhuma pode apenas arquivos de restauração, tente alguns arquivos, mas ainda falha parcial parcialmente bem sucedido:

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD

Você não pode ajudar um resfriado, é que foi escrito para excluir arquivos no disco? A probabilidade de recuperação não é, ah, você pode restaurar uma contagem de alguns poucos, talvez apenas importante MYD arquivos de dados podem ser restaurados.

Então, primeiro de todos os nomes de arquivo redirecionado para um arquivo no arquivo:

ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.txt

Filtrar todos nome do arquivo de banco de dados MySQL salvo como mysqltbname.txt.

Scripting recuperar arquivos:

while read LINE
do
    echo "begin to restore file " $LINE
    ext3grep /dev/vgdata/LogVol00 --restore-file $LINE
    if [ $? != 0 ]
    then
        echo "restore failed, exit"
       # exit 1 公众号:Java后端
    fi
done < ./mysqltbname.txt

Execução, executar cerca de 20 minutos, mais de 40 recuperação de arquivo, mas ah não é suficiente, temos cerca de 100 mesas, cada mesa frm, myd, MYI três documentos, como dizem que há cerca de mais de 300 ah!

Vai voltar arquivos anexados a um banco de dados existente, mas também para as permissões de arquivo para 777, restart MySQL, pode ser considerado parte das costas de dados, mas o cliente é importante para assinar os dados do comparecimento, o relato lado do telefone de dados (estes dados são ditas por cliente fazer o desempenho do empregado) para não vir ah volta.

Suposto? Meio e tentou outra extundelete ferramenta, com a gramática ext3grep basicamente o mesmo princípio deve ser o mesmo, mas é dito para restaurar por diretório.

Bem, experimentá-lo:

extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh

Logo em seguida, a recuperação não sai! ! ! ! ! ! ! ! Esses arquivos foram destruídos. Com a liderança do relatório, a implementação do Plano B agora ...... desespero casa do trabalho. (Weekend, voltar e fazer uma pausa, pensar em uma maneira)

Teve uma ideia: Binlog

Na manhã seguinte, acordei cedo na manhã (problemas cardíacos ah), a parte de trás do computador, vá para a empresa (neste fim de semana ser reembolsado, e não criticado, notificação, multas, demissão sobre o bem, mas também o que o ah fim de semana).

Ainda executar ext3grep, extundelete, receita ah que irá colocar os sistemas de rack de servidor de teste, pode olhar para os dados para encontrar maneiras de consertá-lo.

Realizado em um mysqldump servidor de teste, recuperar arquivos, recuperar tampa traseira do arquivo, adicionar permissões para o arquivo, reiniciar MySQL.

Espere, espere, não há Binlog isso? Nossos serviços são obrigados a abrir Binlog, talvez você possa recuperar dados Binlog nele?

Então, encontrar arquivos de despejo log binário do nome do arquivo de um total de três:

mysql-binlog0001
mysql-bin.000009
mysql-bin.000010

Restaurar cerca de 0001:

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/mysql-bin.000001

Na verdade não ...... olhar para os outros dois arquivos, mysql-bin.000010 provavelmente algumas centenas de MB, deve ser um pouco complicado, execute o comando restore, realmente um sucesso!

SCP o mais rápido possível para o servidor de teste. Execução Binlog restauração:

mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p

Digite a senha, preso (um bom sinal), depois de uma longa espera finalmente acabou. Abra o aplicativo, oh, graças a CCTV, MTV, os dados de volta!

pós-escrito

Também quero lembrar o acidente, ele deixará de cometer o mesmo erro. acidente reflexão da seguinte forma:

Eles não antecedência para organizar o seu tempo deste manutenção do servidor MM explicar a situação pior, e ele não atribuem importância à gestão de caos, confusão processo. Um sistema de produção em linha, quaisquer alterações deve primeiro planejar e depois mover.

problemas de backup automático, ninguém cheques. Fora de linha pessoal de backup 1K por download de arquivos a partir do servidor, mas nunca a sério. Nós precisamos de uma clara responsabilidade no local de trabalho.
Depois do acidente, ele não descobriu, fazendo com que parte dos dados gravados no disco, resultando em problema irrecuperável. Necessidade de programa de monitoramento de aplicativo de gravação, uma vez que o serviço é anormal, alertas SMS a pessoa responsável.
De acordo com comentários lembretes, mais uma: Você não pode usar o usuário root para operar. Você deve oferecer diferentes níveis de privilégios de usuário no servidor.

[Número Yunqi de produtos aulas on-line] têm técnicos especialistas para compartilhar todos os dias!
Cursos Endereço: https://yqh.aliyun.com/zhibo

Participe da comunidade, com especialistas face a face, para manter a par dos mais recentes desenvolvimentos do curso!
[Número Yunqi comunidade sala de aula online] https://c.tb.cn/F3.Z8gvnK

link original
Este artigo conteúdo original comunidade Yunqi não pode ser reproduzido sem permissão.

Lançado 2315 artigos originais · Louvor obteve 2.057 · Visualizações 1,56 milhões +

Acho que você gosta

Origin blog.csdn.net/yunqiinsight/article/details/105372895
Recomendado
Clasificación