mysql 灾难型恢复

34r2312

如果.MYD文件丢失或者误删除，有没有备份，也没有二进制日志，还没有备库，那怎么办呐？


案例：灾难恢复
在没有备份，没有日志，没有备库，数据文件还被删除的情况下恢复数据

恢复思路

在系统中删除文件并非真正在存储中抹去数据，而是仅仅是标示对应的block块可以被重新分配，因此，数据还是在的，只是正常方式读取不到
因此，假如可以通过非正常方式读到这些数据，在重重新保存文件，那么数据就还原回来了、


mysql 配置
为了模拟一次数据误删除，并且使用ext3grep恢复数据，需要以下环境准备
1，创建一个单独的分区。
2，将MSYQL数据拷贝到该分区中
3，将新的分区挂载到mysql数据文件目录

原因？ext3grep 无法操作一挂载的分区，因此mysql的数据应该存在一个独立分区上，这样方便挂载和卸载


使用ext3grep 查看文件系统:

ext3grep  可以帮助我们通过文件系统读取底层数据。
--ls --inode 可以查看指定文件或目录的信息
ext3grep /dev/sdb1  --ls --inode 2

使用ext3grep 恢复文件
使用--restore-inode的参数组合，我们可以恢复指定的文件
ext3grep /dev/sdb1  --restore-inode 12354

　本文所用到的工具链接：

1.ext3grep:https://code.google.com/p/ext3grep/
ext3grep依赖e2fsprogs-devel和e2fsprogs-lib包,因此需要先安装他们才能编译ext3grep
tar  xvf  ext3grep-0.10.2.tar.gz -C /home
cd xt3grep-0.10.2
./configure
make
mkae install.

如果是ext4文件系统，使用下面的工具即可使用方法和ext3一样的
extundelete /dev/sdb1 --inde 2
extundelete /dev/sdb1 --restore-inode 57146
extundelete

模拟案例如下：


>drop table t2;
/etc/init.d/mysqld stop
mount  查看mysql数据在那个分区
ll -id  /usr/local/mysql 查看mysql的inode
2 drwxr-xr-x 3 root root 4096 Jan 14 16:52 mysql
umount /  /var/lib/mysql
ext3grep /dev/sdb1  --ls --inode 2
ext3grep /dev/sdb1  --ls --inode 48961(db1 具体某一库的inode)
接下来根据iNode 恢复到一个空目录
cd /root/test
ext3grep  /dev/sdb1 --restore-inode  48961
mv test/RESTORE-FILEs/inode.48691  test/RESTORE-FILEs/t2.MYD
mv test/RESTORE-FILEs/inode.48692  test/RESTORE-FILEs/t2.MYI
mv test/RESTORE-FILEs/inode.48693 test/RESTORE-FILEs/t2.frm
mount /dev/sdb2  /var/lib/mysql
cp t2.*  /usr/local/mysql/data/db1
chow -R mysql.mysql . * (pwd =/var/lib/mysql/db1)
/etc/mysqld start
最后在查看数据是不是完整、