015.Linux系统删根数据恢复
重要声明：
本文档所有思路来自于誉天教育，由本人（木二）在实验环境验证通过；
您应当通过誉天邹老师或本人提供的其他授权通道下载、获取本文档，且仅能用于自身的合法合规的业务活动；
本文档的内容仅供学习交流，未经以上任何一方事先书面同意，您不得向任何第三方披露本手册内容或提供给任何第三方使用；
未经以上任何一方事事先书面许可，任何单位、公司或个人不得基于商业目的擅自摘抄、翻译、复制本文档内容的部分或全部，不得基于商业目的以任何方式或途径进行传播和宣传。
由于产品版本升级、调整或其他原因，本文档内容有可能变更。以上双方保留在没有任何通知或者提示下对本文档的内容进行修改的权利（如在CentOS7上的操作变动）。
本文档仅针对特定局点或者项目，特定环境（如以上为CentOS6.8验证），不作为通用的文档或者手册进行指导，不具备流通复制的可行性。若用户自行复用，产生的任何后果（包括经济损失，二次故障，人身安全，如挨揍被开除），誉天及本人不负有任何责任。
如若发现本文档存在任何错误，请与誉天教育或本人取得直接联系。
一 场景介绍
Linux环境中，由于误操作将/已删除，需要结合其他主机进行修复：
节点 | IP | 数据所在目录 | 备注 |
|---|---|---|---|
node1 | 172.24.8.51 | /mysqldb | 模拟故障机 |
node2 | 172.24.8.52 | —— | 应用数据恢复-集群节点2 |
/dev/sdb1 /mysqldb ext4 defaults 0 0提示：本环境为模拟环境，应用数据保存在独立的分区，生产环境结合实践谨慎操作；
本操作不保证绝对恢复，仅处于思路提供进行模拟；
若node2和node1非集群主机（即/etc等目录也不一致），可参考若《004.extundelete恢复文件》将相关非一致性目录恢复；
整个全过程拆分为应用数据恢复+系统修复，必须先恢复应用数据，防止解压系统相关文件的时候覆盖掉应用数据。
二 模拟场景
2.1 建立模拟环境
1 [root@master ~]# mkdir /mysqldb
2 [root@master ~]# mount /dev/sdb1 /mysqldb
3 [root@master ~]# mkdir /mysqldb/test
4 [root@master ~]# mkdir /mysqldb/prod
5 [root@master ~]# echo 'This is file01!' >>/mysqldb/file01
6 [root@master ~]# echo 'This is file02!' >>/mysqldb/file02
7 [root@master ~]# echo 'This is file03' >>/mysqldb/test/file03
8 [root@master ~]# echo 'This is file04' >>/mysqldb/prod/file04
9 [root@master ~]# md5sum /mysqldb/file01
10 [root@master ~]# md5sum /mysqldb/file02
11 [root@master ~]# md5sum /mysqldb/test/file03
12 [root@master ~]# md5sum /mysqldb/prod/file04
2.2 执行删除操作
1 [root@node1 ~]# rm -rf /* #模拟删根三 应用数据恢复
3.1 卸载应用数据所在盘符
将应用数据目录/mysqldb所在磁盘采用物理形式从node1卸载挂载至node2节点。
3.2 node2安装相应恢复软件
参考《004.extundelete恢复文件》在node2节点安装extundelete软件。
3.2 查询可恢复数据
1 [root@backup /]# extundelete /dev/sdb1 --inode 2
提示：建议在其他机器将需要恢复的数据所在硬盘进行挂载，或使用U盘进入系统后，将master中/data所在设备/dev/sdb1挂载为只读。
3.3 执行恢复
1 [root@backup ~]# extundelete /dev/sdb1 --restore-all #恢复所有文件提示：--restore-file和--restore-directory后面指定的是所需恢复文件或目录为相对路径，即相对于原来文件的存储路径而言的，如上所示原来文件的存储路径是/data/file01，则参数后面直接指定file01文件即可，即相对于/data根目录下的file01文件。若如果原来文件的存储路径是/data/test/mytest.txt，那么在参数后面通过“test/mytest.txt”指定即可。若如果原来目录的存储路径是/data/oracle，则参数后面直接指定/oracle目录即可。
在文件恢复成功后，extundelete命令默认会在执行命令的当前目录下创建一个RECOVERED_FILES目录，此目录用于存放恢复出来的文件，所以执行extundelete命令的当前目录必须是可写的。
1 [root@node2 ~]# ll RECOVERED_FILES/
1 [root@node2 ~]# md5sum RECOVERED_FILES/file01
2 [root@node2 ~]# md5sum RECOVERED_FILES/file02
3 [root@node2 ~]# md5sum RECOVERED_FILES/test/file03
4 [root@node2 ~]# md5sum RECOVERED_FILES/prod/file04
提示：根据之前的md5值对数据完整性进行验证。
3.4 还原数据
1 [root@node2 ~]# md5sum RECOVERED_FILES/file01
2 [root@node2 ~]# md5sum RECOVERED_FILES/file02
3 [root@node2 ~]# md5sum RECOVERED_FILES/test/file03
4 [root@node2 ~]# md5sum RECOVERED_FILES/prod/file04提示：还原之后可将sdb磁盘物理卸载，避免node2写入数据至该目录；
建议物理卸载后在node1系统没有修复之前不要插回node1节点。
四 系统修复
4.1 进入救援模式
关闭node1，通过挂载系统相应的ISO镜像，进入救援模式。
4.2 将相应目录进行备份
1 [root@node2 tmp]# tar -zcvf /tmp/etc.tar.gz /etc/
2 [root@node2 tmp]# tar -zcvf /tmp/bin.tar.gz /bin/
3 [root@node2 tmp]# tar -zcvf /tmp/lib64.tar.gz /lib64/
4 [root@node2 tmp]# tar -zcvf /tmp/lib.tar.gz /lib/提示：将node2中/etc、/bin/、/lib64/、/lib/使用tar进行打包，以上为系统修复必须进行备份的目录；
若有其他目录需要恢复参考此操作即可，也可先修复系统，将系统重新拉起之后进入系统再使用其他方式（如extundelete或scp）将非一致性文件修复。
4.3 node1进入支持网络的救援模式
选择语言
选择键盘
配置网络，yes。
选择能和node2通信的网卡并配置能和node1通信的IP。
Manual configuration：手动静态配置
IPV4 Address：172.24.5.51/24
关闭IPV6
救援模式会将node1本身根目录在救援环境下挂载至/mnt/sysimage。
提示无任何Linux分区，可进入救援模式的shell环境。
进入救援模式的shell环境。
验证网络情况
验证救援模式下的node1和正常的node2网络是否正常。
4.4 查看并激活磁盘分区
查看根目录所在磁盘分区信息，如图所示分区为LVM分区。
确认node1磁盘根分区所在lvm分区，如图所示为/dev/VolGroup/LogVo101
激活根分区所在的该LVM逻辑卷，并挂载至相应目录
1 # lvchange -a y /dev/VolGroup/LogVol01 #激活lvm分区
2 # mkdir /delroot #创建用于挂载node1根分区的目录
3 # mount /dev/VolGroup/LogVol01 /delroot
提示：挂载之后，在救援模式中的/delroot目录，即为原node1的根目录。
4.5 恢复相应数据
1 # scp root@172.24.8.52:/tmp/*.gz /delroot/tmp通过scp命令，将node2相应的备份文件复制至node1原根新挂载的目录/delroot/tmp目录。
1 # tar -zxvf bin.tar.gz -C /delroot/
2 # tar -zxvf etc.tar.gz -C /delroot/
3 # tar -zxvf lib64.tar.gz -C /delroot/
4 # tar -zxvf lib.tar.gz -C /delroot/将所有node2备份的gz包，在node1救援模式下全部解压至node1原根新挂载的根目录/delroot。
4.6 改变根目录位置
重启系统，参考5.3步骤再次进入带网络（即配置IP）的救援模式。
1 # exit
当再次进入救援模式的时候，已提示可以使用chroot切换跟目录。
切换根目录。
4.7 修复引导程序
1 # grub-install /dev/sda
4.8 修复内核
1 # mkdir /media
2 # mount /dev/cdrom /media/
3 # cd /media/Packages/
4 # rpm -ivh kernel-2.6.32-642.el6.x86_64.rpm --force
提示：若出现以上错误，可将所需要包全部进行安装，如下所示：
若需要修复的node1内核版本和所挂载的光盘中的内核版本不一致，可从node2下载匹配node1相应的内核版本所有相关rpm包scp至node1，再进行安装。
4.9 重启并验证
若出现以下界面，无法正常进入系统，可手动尝试加载grub.conf并启动。
手动执行以下加载grub命令
1 root (hd0,0)
2 kernel /vmlinuz-2.6.32-642.el6.x86_64 ro root=/dev/VolGroup/LogVol01 selinux=0
3 initrd /initramfs-2.6.32-642.el6.x86_64.img
进入系统
4.10 修复网络
1 # rm -rf /etc/udev/rules.d/70-persistent-* #删除网卡rule
2 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 #修复node1IP
3 DEVICE=eth0
4 TYPE=Ethernet
5 ONBOOT=yes
6 NM_CONTROLLED=yes
7 BOOTPROTO=static
8 IPADDR=172.24.8.51 #将IP配置为node1正确地址
9 NETMASK=255.255.255.0
10 GATEWAY=172.24.8.2
11 DNS1=223.5.5.5
12 # vi /etc/sysconfig/network
13 HOSTNAME=node1 #将主机名修改为node正确主机名提示：由于node1中的所有配置是由node2恢复，因此对于特定配置需要逐步手动修改，以上为网卡配置修复示例;
实际生产环境所有非一致性配置请根据实际情况进行修改。
4.11 修复引导grub配置文件
1 [root@node2 ~]# scp -p /boot/grub/grub.conf root@172.24.8.51:/boot/grub/提示：若node2和node1不一致（如内核相关不一致），可参考node2，手动写node1的grub.conf；
若node2和node1一致（通常指集群环境），可直接从node2的grub.conf复制至node1即可。
五 应用数据恢复至node1
5.1 加载磁盘
将步骤三所恢复的磁盘物理加载至已恢复系统的node1节点。
5.2 挂载分区
1 [root@node1 ~]# fdisk -l /dev/sdb #确认加载是否正常
2 [root@node1 ~]# mount /dev/sdb1 /mysqldb/ #挂载目录
3 [root@node1 ~]# ll /mysqldb/ #查看数据
5.3 确认验证
1 [root@node1 ~]# md5sum /mysqldb/file01
2 [root@node1 ~]# md5sum /mysqldb/file02
3 [root@node1 ~]# md5sum /mysqldb/test/file03
4 [root@node1 ~]# md5sum /mysqldb/prod/file04
腾讯云开发者
