首页 > 代码库 > 手一抖误删了根目录 /usr 之后的挽救过程

手一抖误删了根目录 /usr 之后的挽救过程

一切悲剧来源于写的Shell没有好好检查,执行后把开发机的根目录 /usr 目录给删除了,而且是root执行,众所周知,/usr目录里有大量的应用层程序,删除之后导致大量命令无法使用,如 ssh / rz / sz / nc / wget /yum 等,不夸张地说,当时就要不行了。。好吧,首先想到的挽救方式就是到另一个虚拟机下将 /usr目录整个拷贝过来,然而发现,没有命令可以往这台机器里拷东西了,上天入地无门。。

好在,这台机器是虚拟机,一切都是虚的,虚的比实的更能应付变化(在某些情况下不对,后面说)。。

于是,用vmware的虚拟磁盘热加载特性,赶紧开了另一个虚拟centos机(后面一律用centos-rescue指明),然后添加一个全新的虚拟磁盘,挂载之后,将 /usr 目录拷贝到挂载的目录,解除挂载,卸掉虚拟磁盘。然后再加入出事的虚拟机(后面一律叫 centos-pity),同样是挂载,将 /usr 拷贝到根 / 目录下,拷贝完立马执行几个命令试试 wget  / rpm / yum  发现, 有些命令能成功,有些提示依赖的 .so 缺失,明显是 yum 系统乱了。。。尼玛哪都可以乱,yum 包管理课别乱,哎!

于是,开始整理yum系统,由于 centos-pity 是主要工作用的开发机,里边安装了大量开发使用的第三方包,主要是c库和python库,整个整理过程历时2个小时左右,只要是各种 yum -y remove XXX 然后 yum -y install XXX , 即将原有的东西先删除然后再安装。。最后,终于看起来yum系统稳定了,到一个C项目里执行 configure && make 都正常了,好开心。。

打铁趁热,之前那么被动就是因为吃了没有及时快照的苦,赶紧关了centos-pity , 用vmware打了个漂亮的快照,心里的石头放下了,开启虚拟机打算进入正常工作,然后,centos-pity 启动比之前慢了好多,最后停止了(一段白条),按F5看输出,尼玛的! lv-root 没有能正常启动。。,直观感觉,往根分区硬删掉一块东西再拷入一块大小不一样的东西,会将分区搞坏,这下事情搞大了。。

这里介绍一下centos-pity的硬盘和分区情况,一开始新建虚拟机时用了一块默认的硬盘20G,叫 sda 然后安装了 centos-6.2-minimal, 这个发行版会将/sda切成两块 , /sda1 挂载到 /boot 目录并安装系统, /sda2 变成一个pv并加入一个默认叫 VolGroup 的逻辑卷组,在VolGroup卷组上再新建2个逻辑分区 lv-root ,lv-swap, 其中,lv-root作为根分区挂载的是根目录 / , 我的主要工作就是在根目录 / 下,比如开发环境安装在 /usr 下,项目代码在 /data 下, 用了一段时间后,磁盘空间不够了,我又增加了一块虚拟硬盘,叫 sdb(100G) ,然后在上面新建pv,同样加入 VolGroup , 然后为 lv-root 逻辑分区扩容,扩到100G 左右。。

所以,lv-root 一出问题,心就慌了,里面是几个月的工作。。

初始想法还是利用 centos-rescue, 赶紧将 sda sdb 从 centos-pity 卸载,然后插入centos-rescue 上, Centos-rescure 是默认安装得到的,只有一块硬盘20G,分区类似上面说的sda1 , sda2(lvm) 的情况,现在centos-pity的两块虚拟硬盘加入后,作为 centos-rescue 的 sdb ,sdc 出现, 系统启动后,又傻了。 centos 默认建立的逻辑眷族都叫 VolGroup , 这导致出现了名字冲突而无法正常使用(两个VolGroup, 两个 lv-root 等) ,之前在另外的场合试图人工修改过lvm名字冲突问题,深知水很深,这次不打算人工搞。。

于是,先将 sdb sdc 又卸载了,然后再进入 centos-rescue , 没错,我打算直接改掉 centos-rescue的默认卷组的名字

vgrename VolGroup VolGroupNew

vgchange -ay VolGroup

执行完后用 vgs, lvs 等查看都是正常的,好吧,插入 sdb sdc 再次重启,又傻了。。。kernel panic ,挖了了去。。

 

一番搜索,发现lvm尼玛是傻逼,vgrename改名字后,尼玛不会自己修改 /boot/grub/grub.cfg 配置里的名字,grub.cfg boot选项还是从 VolGroup-lv-root 启动,而这个分区已经没有了,好吧,人工修改为 VolGroupNew-lv-root 并将其他地方都换为 VolGroupNew ,再重启, 又傻了。。。filesystem checking 失败,挖了个去。。

一番搜索,发现lvm真是傻逼,/etc/fstab 里的挂载项目也需要人工修改,修改后再重启,这次OK了,lvs一下出现

lv_root VolGroup -wi-ao---- 96.57g
lv_swap VolGroup -wi-a----- 1.94g
lv_root VolGroupNew -wi-ao---- 17.57g
lv_swap VolGroupNew -wi-ao---- 1.94g

centos-pity 的两个盘都以 lvm 逻辑分区的形式在 centos-rescure出现了,赶紧将 /dev/VolGroup/lv_root 挂载到一个目录,然后将里边重要的目录拷贝出来,这里因为前面lvm各种折磨,不打算用 lvm 了,直接用 vmware 新增一个普通的虚拟磁盘,叫 sdd , 这块就是干净的普通磁盘,mkfs.ext4 新建一个文件系统并挂载,然后将重要的项目文件拷进去,再卸载。 然后将这个虚拟磁盘放入 360 云盘里,直接上传到云。。这叫吃一亏长一智,以后重要的项目数据都这么来,直接用普通虚拟磁盘不做任何lvm,空间不够增加磁盘就行了,磁盘文件都放入云盘及时同步,也不用惦记着去做快照了,一旦发生问题,新建一台虚拟机,挂上虚拟磁盘,屁事没有,又可以开始工作了。。

 

好了,数据算是挽救回来了,接下去想救救 centos-pity , 于是再将磁盘挂回去启动,出现错误

"打不开文件“E:\00-worker-centos\centos-pity.vmdk”:

该虚拟机的某个磁盘已经由虚拟机或者快照使用。"

这个错误还没解决,据说是因为虚拟机centos-pity记录了一些中间状态导致的。反正数据救回来了,开发环境有专门的脚本安装,干脆新建个虚拟机重建一个系统,再用安装脚本安装开发环境。

 

 

参考

http://www.novell.com/coolsolutions/appnote/19386.html

http://www.duo66.com/post-4095.html