大过年的，虚拟化服务器崩溃了，正感叹它会挑日子呢，其实并不是那么回事——已经坏了段时间，客户早早地就想着过了年再折腾，无奈财务要用，所以又催着我们修复。
也不知道从什么时候开始，年底要钱成了我的主要工作，印象最深的是前年——还以为是去年，刚才特地查了聊天记录才确认是前年了——有个当初听上去不错的项目竣工，年底结算的时候才发现，这个装饰公司的名称真没起错，果然是不三不四。
要钱的过程，就不描述了，对付无耻之极的人，只能用非常手段，虽然非常艰辛，但是不管怎么说，钱总算是要回来了，而且连质保金（还没到日子）都一并要了回来，觉得相当不错了。
言归正传，年底钱难要，心情难免抑郁，但是有技术活来了，咱绝不打一分折扣，得给人家干好了。这不，忙活了好几天，总算是八九不离十了，今天给大家整理一下灾难恢复过程，觉得有用的朋友们，关注一下鄙人，点个赞，也算是为我深夜码字加个油吧，先谢谢了。
这是一台XenServer服务器，后面挂载着我们公司自己开发的分布式存储系统，虚拟机都在存储池里面，所以我接到电话并不是太担心。
客户发来截图，xencenter连接不上服务器。那就到机房看一下嘛，也许重启一下就会好呢？嘿嘿。
事实证明，我想多了，这个画面可不是什么好苗头，顿时有种不祥的预感，重启果然是无效的，让客户再次重启，这回选择安全模式，输入命令：journalctl -xb
好家伙，难怪系统起不来了，这是文件系统坏了啊，当然也可能是硬盘坏了；也不知道能不能修复，先试试看呗，让客户执行命令：fsck /dev/sda5，还以为有机会喝口水，等结果，可是客户一秒钟就发来图片
Fsck命令根本就没法执行，这……玩得有点大啊，硬盘就没闪个黄灯？
好吧，服务器呼啦啦地跑得起劲呢，没有任何故障指示灯。
看来要放弃治疗了，重装之前，最好有虚拟机和虚拟硬盘的对应关系（vm-uuid、vdi-uuid）,所以，此时执行命令：xe vbd-list
呃……这个时候，我感到事态严重，要啥啥没有，这可咋整？
把硬盘拆下来，挂载到centos系统，想拿到/var/xapi/state.db文件，这个文件能用记事本打开，里面记录着虚拟机的配置以及各个uuid，然而目录下空空如也，有点慌了。尝试fsck修复，完事后挂回去，还是起不来。
完犊子，芭比Q了。
换我们的硬盘，装XenServer。可惜，装上容易，恢复难啊，痛苦的旅程就此拉开帷幕——没错，你要看的好戏才刚刚开始。
安装我们自己的分布式存储系统，以便挂载网络存储： ./installer7 -M，报错了，少一堆资源包，正常正常，那就先更新源吧， 先备份一下：cp CentOS-Base.repo CentOS-Base.repo.backup，然后编辑文件：vim CentOS-Base.repo
提示没有vim命令，好吧，那就yum install vim，安装完成后，再执行vim CentOS-Base.repo。
我在谁？我在哪儿？我在干什么？有必要安装vim吗？FinalShell可以直接打开、编辑、保存的啊！
好的好的，自从有了FinalShell，省事儿多了，早就抛弃Xshell了。注意，没拿广告费啊，开源免费软件，好用，就是Java开发的，有点占内存。
Yum clean all
Yum makecache
yum-config-manager --enable 失败，好吧好吧， yum install yum-config-manager，不对，那应该是yum install yum-utils，Linux就是这样了，总是缺这缺那，要一个个地补。
yum-config-manager --enable，总算妥了，但是挂载存储还是报错，于是又执行命令：yum install fuse
/usr/local/exfs/bin/exfsmount /exfs，分布式存储系统挂载到/exfs路径。
挂载容易，怎么把它设置为Xenserver的默认存储呢？而且里面有数据，不敢轻举妄动，这是个技术活儿。
如果不是分布式存储系统，只是服务器里面的另外一块硬盘，或者另外一个阵列组成的磁盘，那么操作步骤如下：
1、通过pvscan查看原存储的UUID：
VG_XenStorage-a17d3701-3c00-22de-840a-b04e17de1f29
2、通过xe host-list 命令查看重装后的host的UUID号：
b471cd67-80ad-45ea-aa06-4870cfb67b1d
3、将PVscan命令得到的UUID号导入存储，命令如下：
xe sr-introduce uuid=a17d3701-3c00-22de-840a-b04e17de1f29 type=lvm name-label="Disk2" content-type=user
4、用命令：ll /dev/disk/by-id查看存储设备的ID：
ata-ST3000DM008-2DM166_Z504KYKY
5、通过以上的sr-uuid号、by-id号、host的uuid号创建出pbd的UUID号：
Xe pbd-create sr-uuid=a17d3701-3c00-22de-840a-b04e17de1f29 device-config:device=/dev/disk/by-id/ata-ST3000DM008-2DM166_Z504KYKY host-uuid=b471cd67-80ad-45ea-aa06-4870cfb67b1d
此时，在xencenter控制台，只要点击“Disks”存储，然后“Rescan”，就能搜索原来的虚拟磁盘（搜索不到，就执行命令xe pbd-plug uuid=刚才得到的pbd的uuid），运气好的话，有名称和描述，很容易匹配到原来的虚拟机，如果只显示虚拟磁盘的容量，没有其他信息怎么办？
那就新建虚拟机，但是不要开机，然后“Attach Disk”，
在列表中随便选一块虚拟磁盘，看看你的运气怎么样。
然后把新建虚拟机的时候，新建的虚拟磁盘删除，只用刚才“Attach Disk”添加的虚拟磁盘启动虚拟机，如果能启动，就自然能看到是什么系统，如果无法启动，那么这块虚拟磁盘可能不是系统盘，而是虚拟机的存储盘，记录下面，后面再挂载到可启动的虚拟机里面查看内容。
问题来了，我们现在用的是外挂的分布式存储系统，pvscan命令是无效的，无法获取到存储的uuid，那后面的一系列操作都是无法运行的。
也就是说，我必须找到原存储的uuid，否则无法进行到下一步。
前面说到，分布式存储系统已经挂载到/exfs路径，那就看一下日志文件吧。
Cd /exfs
Ls
Cat filelog.txt
Sr-mount，就是挂载的存储，每个vhd文件前面都是80785f5e-ef2a-323f-ce2f-6f8eef3d56f6，这个必定是原存储的uuid了。
那就好办了，直接执行命令，导入这个存储即可：
xe sr-introduce uuid=80785f5e-ef2a-323f-ce2f-6f8eef3d56f6 name-label=exfs shared=true type=file device-config:location=/exfs/HGVM1 content-type=user
回到xencenter，看到导入的存储了，然而，里面空空如也，心里难免一阵恐慌。
鼠标右键点击“exfs”（就是刚才导回的存储），选择“repair”，完成后，虚拟磁盘都显示出来了，只不过，非常遗憾，除了容量以外，什么信息都丢失了，先手动标个编号吧，因为没有得到原xenserver系统硬盘中的/var/xapi/state.db文件，此时实在没办法了，只能逐一挂载这些虚拟磁盘，看内容再做决定。
正如前面所说的，先创建一台Win10的虚拟机，然后“Attach Disk”，一个一个地看太慢了，我直接添加几个不同容量的磁盘1号100G、5号200G、12号1000G、13号2000G，然后启动虚拟机，顺利启动，1号100G是个Windows Server，启动后到磁盘管理，可以看到，5号200G无法识别分区类型，判断为Linux系统，12号1000G，可以直接打开，看到很多文件夹，判断为共享盘，按照原来的架构，理应是域控的D盘，挂载在此，正合适；13号2000G，提示是跨区卷，当然不能初始化。此时，记录桌面文件夹的最后修改日期，然后关闭虚拟机。
分析：按照客户提供的信息，这台虚拟服务器里， 有一台Win7，两台Windows Server，两台CentOS，可是现在有这么多虚拟磁盘，明显有重复的，应该是快照。
猜测：4块100G的虚拟磁盘中，有一个是Win7，2个当然是Windows Server，多出来一个，是其中一台Windows Server的快照。而200G的虚拟磁盘，可能是两台CentOS的，多出来的几个，应该是快照；1000G的虚拟磁盘，已经确定，2000G的既然是跨区卷，那至少是2个2000G组成一块磁盘，那就继续操作。
这台名为Win10的虚拟机，改名称为Windows Server-1，断开5号-200G、新增14号2000G，可是忙中出错，断开虚拟磁盘应该是“Detach”，却点了“Delete”，被删除了！
真是屋漏偏遭连夜雨啊，还让不让人活了，算了，先放一边，我们的存储系统有回收站的，稍等再找回来吧，先弄清楚其他虚拟磁盘再说。
趁虚拟机在启动的时候，再新建一台Win虚拟机，“Attach Disk”选择2号100G，结果启动时也显示Windows Server，进系统后，发现与刚才启动的第一台虚拟机，计算机名称相同，原来是同一台虚拟机啊，记录下桌面文件夹的最后修改日期，再重复操作，3号和4号，发现4个100G的虚拟磁盘，全是同一台Windows Server！比对日期后，保留一台，其他磁盘没用了，先留着吧。
这台Win7的虚拟机，改名称为Windows Server-1，为什么呢？因为客户记得Win7是100G的磁盘，但是现在100G的磁盘已经全部挂载过了，根本就没有Win7，由此判断，Win7应该是在坏了的本地磁盘内，所以继续找另一台Windows Server要紧。
“Attach Disk”选择6号200G，启动后，看计算机名称，果然是Windows Server-2，老规矩，还是记下桌面文件夹的最后修改日期，以待比对。
还是这台虚拟机，改为“Attach Disk”7号200G，结果启动的是CentOS，关机；
创建一台新的CentOS虚拟机，“Attach Disk”7号200G，启动正常，暂时就这样不动它。
回到Windows Server-2那台虚拟机，一个一个地“Attach Disk”后面的几个200G，发现全是同一台Windows Server，用前面的方法，比对日期，使用最新的作为正式的系统盘，其他的几个200G的虚拟磁盘就没用了，刚才误删除的那个，应该是另外一台CentOS，那就把它找回来吧。
mkdir /mnt/restore
/usr/local/exfs/bin/exfsmount -m /mnt/restore/
cd /mnt/restore/trash
mv *.vhd /exfs/HGVM1/
重新Rescan，5号200G又回来了，创建一台新的CentOS虚拟机，“Attach Disk”5号200G，启动正常。至此，操作系统全部恢复，接下来，恢复Windows Server的存储，前面已经在Windows Server-1挂载了，13和14，并且在“磁盘管理”中，跨区卷已经正常工作，如下图所示，是那块3.9T的磁盘。
此时，把15和18（16和17无法与15组合成跨区卷，18成功组合）挂载到Windows Server-2，并且在“磁盘管理”中，跨区卷已经正常工作，也是一块3.9T的磁盘，但是文件内容大有不同，交给客户去比对。
此时，虚拟服务器的恢复暂时告一段落，待客户检查文件后，根据客户反馈的信息，再挂载剩余的虚拟磁盘（16、17、19、20），还需要多次重复的操作，才能最终完成恢复工作。
总结，再好的技术，也比不上勤快的备份有效！
