一切悲剧来源于写的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
手一抖误删了根目录 /usr 之后的挽救过程,布布扣,bubuko.com
原文：http://www.cnblogs.com/jiayy/p/3750176.html