采用即时虚拟机恢复技术，企业可以直接从备份文件本身运行该功能，从而立即将虚拟机还原至生产环境。这有助于企业缩短还原时间并更好地实现恢复时间目标 (RTO)，因为我们无需将备份存储中的任何数据复制到生产存储中。相反，我们仅需直接从备份目标启动虚拟机，用户便可以即时访问其文件和应用程序。准备就绪之后，我们可以直接使用 VMware Storage vMotion或其他迁移技术将虚拟机实时迁移回生产环境，同时为用户提供访问权限。   　　在 Veeam Backup & Replication 中执行即时虚拟机恢复的过程如下：          选择虚拟机和所需的恢复点之后，启动 vPower 技术。vPower 是一项 NFS 服务，不仅为即时虚拟机恢复打下基础，而且还为大量应用程序级还原和 SureBackup 技术奠定了基石。从本质上讲，vPower 将备份服务器转变为 NFS 服务器，后者在选定的所需恢复点导出包含虚拟机的共享。然后，企业的生产 ESXi 主机可以将该 NFS 共享作为原生数据存储加载，执行启动操作，并以原生内核级方式在经过压缩、重复数据消重的虚拟机上处理读取/写入。   　　为保持实际备份文件的完整性，在新出现的虚拟机内生成所需时间点的快照。这意味着企业可以在生产型环境中为用户提供虚拟机，当虚拟机最终迁移或还原回生产环境时，可以保留包含虚拟机的备份文件完整性。这样，企业仅需将即时虚拟机恢复期间所做的更改提交至生产环境，使存储的备份文件与执行即时恢复之前一样。   　　由于大多数备份存储往往是第 2 层类型的存储(在比生产环境速度更慢的旋转式磁盘上运行)，因此您可以想象得到，在此过程中性能可能多少会受到影响。当然，这并不意味着它将成为永久解决方案，但即时虚拟机恢复可以让虚拟机恢复正常运行，使企业能够以有限的方式立即访问数据，直到将虚拟机迁移回生产存储阵列。为了帮助缓解性能问题，您可以将对虚拟机进行的更改和写入重定向到另一个数据存储。您可以将这些托管 VMware 快照更改的恢复日志以及指向此类日志的元数据文件放在非 vPower NFS 数据存储上，特别是底层存储速度更快的数据存储。   　　最终处理即时虚拟机恢复(即：提交更改并将虚拟机移回生产环境)时，企业可以选择几种不同的可用性级别：复制、Quick Migration(快速迁移)和 Storage vMotion。   　　1.实际上，您可以使用 Veeam 中的复制功能或 VMware 中的克隆功能将即时虚拟机恢复故障切换到生产存储。        但这两种选项均需要计划维护时段，当然也需要一些停机时间(从恢复的虚拟机故障切换到复制的虚拟机时)。届时，即时恢复的虚拟机将关闭，系统将所做的最终更改复制或克隆到新虚拟机，然后启动该虚拟机。   　　2.Quick Migration(快速迁移)是 Veeam 为了将即时恢复的虚拟机故障切换到生产环境而引入的另一项技术。        这实质上与复制和克隆相同，但其执行方式可将在切换期间对生产环境造成的干扰降至最低。快速迁移仅仅在生产存储上还原即时恢复的虚拟机，然后利用快速的后台进程将更改从目标虚拟机复制到源端虚拟机。当这两个虚拟机同步时，原始备份虚拟机就会暂停，然后在目标主机上继续操作。   　　3.另一种更可取且不需要停机的选项是 VMware Storage vMotion。        由于虚拟机以原生方式呈现给 ESXi，因此已获得其许可的企业仅需利用 Storage vMotion 即可将还原的虚拟机快速迁移到生产存储，而不会导致任何停机。这一过程基本上是指从 Veeam 呈现的 NFS 存储中提取虚拟机并将其放回生产存储，而绝不会使虚拟机提供的服务出现任何中断。   　　即时虚拟机恢复可在现代数据中心内提供 24x7 可用性，是一项改变整个行业规则的真正创举。企业能够以有限的方式立即启动并运行服务，避免生产力和收入损失，从而节省时间和资金。

一、服务器数据恢复故障描述 机房突然断电导致整个存储瘫痪，加电后存储依然无法使用。经过用户方工程师诊断后认为是断电导致存储阵列损坏。 整个存储是由12块日立硬盘（3T SAS硬盘）组成的RAID-6磁盘阵列，被分成一个卷，分配给几台Vmware的ESXI主机做共享存储。整个卷中存放了大量的Windows虚拟机，虚拟机基本都是模板创建的，因此系统盘都统一为160G。数据盘大小不确定，并且数据盘都是精简模式。 二、服务器数据恢复备份数据 将故障存储的所有磁盘和备份sss数据的目标磁盘连入到一台Windows Server 2008的服务器上。故障磁盘都设为脱机（只读）状态，在专业工具WinHex下看到连接状态如下图所示：(图中HD1-HD12为目标备份磁盘，HD13-HD24为源故障磁盘，型号为HUS723030ALS640)： 图一： 使用WinHex 对HD13-HD24以底层方式读取扇区，发现了大量损坏扇区。初步判断可能是这种硬盘的读取机制与常见的硬盘不一样。尝试更换操作主机，更换HBA卡，更换扩展柜，更换为Linux操作系统，均呈现相同故障。与用户方工程师联系，对方回应此控制器对磁盘没有特殊要求。 使用专业工具对硬盘损坏扇区的分布规律进行检测，发现如下规则： 1、损坏扇区分布以256个扇区为单位。2、除损坏扇区片断的起始位置不固定外，后面的损坏扇区都是以2816个扇区为间隔。 所有磁盘的损坏扇区分布如下表（只列出前3个损坏扇区）： 临时写了个小程序，对每个磁盘的损坏扇区做绕过处理。用此程序镜像完所有盘的数据。 三、服务器数据恢复故障分析 1、分析损坏扇区 仔细分析损坏扇区发现，损坏扇区呈规律性出现。 -每段损坏扇区区域大小总为256。-损坏扇区分布为固定区域，每跳过11个256扇区遇到一个坏的256扇区。-损坏扇区的位置一直存在于RAID的P校验或Q校验区域。-所有硬盘中只有10号盘中有一个自然坏道。 2、分析分区大小 对HD13、HD23、HD24的0-2扇区做分析，可知分区大小为52735352798扇区，此大小按RAID-6的模式计算，除以9，等于5859483644扇区，与物理硬盘大小1049524，和DS800控制器中保留的RAID信息区域大小吻合；同时根据物理硬盘底层表现，分区表大小为512字节，后面无8字节校验，大量的0扇区也无8字节校验。故可知，原存储并未启用存储中常用的DA技术(520字节扇区）。 分区大小如下图(GPT分区表项底层表现，涂色部分表示分区大小，单位512字节扇区，64bit)： 图二： 四、重组RAID 1、分析RAID结构 存储使用的是标准的RAID-6阵列，接下来只需要分析出RAID 成员数量以及RAID的走向就可以重组RAID。 -分析RAID条带大小 整个存储被分成一个大的卷，分配给几台ESXI做共享存储，因此卷的文件系统肯定是VMFS文件系统。而VMFS卷中又有存放了大量的Windows 虚拟机。Windows虚拟机中大多使用的是NTFS文件系统，因此可以根据NTFS中的MFT的顺序分析出RAID条带的大小以及RAID的走向。 -分析RAID是否存在掉线盘 镜像完所有磁盘。后发现最后一块硬盘中并没有像其他硬盘一样有大量的坏道。其中有大量未损坏扇区，这些未损坏扇区大多是全0扇区。因此可以判断这块硬盘是热备盘。 2、重组RAID 根据分析出来的RAID结构重组RAID，能看到目录结构。但是不确定是否为最新状态，检测几个虚拟机发现有部分虚拟机正常，但也有很多虚拟机数据异常。初步判断RAID中存在掉线的磁盘，依次将RAID中的每一块磁盘踢掉，然后查看刚才数据异常的地方，未果。又仔细分析底层数据发现问题不是出在RAID层面，而是出在VMFS文件系统上。VMFS文件系统如果大于16TB的话会存在一些其他的记录信息，因此在组建RAID的时候需要跳过这些记录信息。再次重组RAID，查看以前数据异常的地方可以对上了。针对其中的一台虚拟机做验证，将所有磁盘加入RIAD中后，这台虚拟机是可以启动的，但缺盘的情况下启动有问题。因此判断整个RAID处在不缺盘的状态为最佳。 五、验证数据 1、验证虚拟机；针对用户较为重要的虚拟机做验证，发现虚拟机大多都可以开机，可以进入登陆界面。有部分虚拟机开机蓝屏或开机检测磁盘，但是光盘修复之后都可以启动。部分虚拟机现象开机如下： 图三： 2、验证数据库；针对重要的虚拟机中的数据库做验证，发现数据库都正常。其中有一个数据库，据用户描述是缺少部分数据，但是经过仔细核对后发现这些数据在数据库中本来就不存在。通过查询 master 数据库中的系统视图，查出原来的所有数据库信息如下： 图四： 3、检测整个VMFS卷是否完整；由于虚拟机的数量很多，每台都验证的话，所需的时间会很长，因此我们对整个VMFS卷做检测。在检测VMFS卷的过程中发现有部分虚拟机或虚拟机的文件被破坏。列表如下： 图五： 六、恢复数据 1、生成数据；MMCloud工程师跟客户沟通并且描述了目前恢复的情况。用户经过对几台重要的虚拟机验证后，用户反应恢复的数据可以接受，接着MMCloud工程师立即着手准备恢复所有数据。 先准备目标磁盘，使用一台dell 的MD 1200加上11块3T的硬盘组成一个RAID阵列。接着将重组的RAID数据镜像到目标阵列上。然后利用专业的工具UFS解析整个VMFS文件系统。 2、尝试挂载恢复的VMFS卷；将恢复好的VMFS卷连接到我们的虚拟化环境中的一台ESXI5.5主机上，尝试将其挂载到的ESXI5.5的环境中。但是由于版本（客户的ESXI主机是5.0版本）原因或VMFS本身有损坏，导致其挂载不成功。继续尝试使用ESXI的命令挂载也不成功，于是放弃挂载VMFS卷。 七、移交数据 由于时间紧迫，先安排MMCloud工程师将MD 1200 阵列上的数据带到用户现场。然后使用专业工具”UFS”依次导出VMFS卷中的虚拟机。 1、将MD 1200阵列上的数据通过HBA卡连接到用户的VCenter服务器上。 2、在VCenter服务器安装“UFS”工具，然后使用“UFS”工具解释VMFS卷。 3、使用“UFS”工具将VMFS卷中的虚拟机导入到VCenter服务器上。 4、使用VCenter的上传功能将虚拟机上传到ESXI的存储中。 5、接着将上传完的虚拟机添加到清单，开机验证即可。 6、如果有虚拟机开机有问题，则尝试使用命令行模式修复。或者重建虚拟机并将恢复的虚拟机磁盘（既VMDK文件）拷贝过去。 7、由于部分虚拟机的数据盘很大，而数据很少。像这种情况就可以直接导出数据，然后新建一个虚拟磁盘，最后将导出的数据拷贝至新建的虚拟磁盘中即可。 统计了一下整个存储中虚拟机的数量，大约有200台虚拟机。目前的情况只能通过上述方式将恢复的虚拟机一台一台的恢复到用户的ESXI中。由于是通过网络传输，因此整个迁移的过程中网络是一个瓶颈。经过不断的调试以及更换主机最终还是无法达到一个理想的状态，由于时间紧张，最终还是决定在当前的环境迁移数据。 八、数据恢复总结 1、故障总结；所有磁盘坏道的规律如下表： 经过仔细分析后得出坏道的结论如下： -除去SN：YHJ6LEUD上的一个自然坏道外，其余坏道均分布于RAID-6的Q校验块中。 -坏道区域多数表现为完整的256个扇区，正好当时创建RAID-6时的一个完整RAID块大小。 -活动区域表现为坏道，非活动区域坏道有可能不出现，如热备盘，上线不足10%，坏道数量就比其他在线盘少（热备盘的镜像4小时完成，其他有坏道盘大概花费40小时） -其他非Q校验区域完好，无任何故障。 结论： 通常情况，经如上坏道规则表现可推断，坏道为控制器生成Q校验，向硬盘下达IO指令时，可能表现为非标指令，硬盘内部处理异常，导致出现规律性坏道。 2、数据恢复总结；数据恢复过程中由于坏道数量太多，以致备份数据时花费了很长世间。整个存储是由坏道引起的，导致最终恢复的数据有部分破坏，但不影响整体数据，最终的结果也在可接受范围内。 整个恢复过程，用户方要求紧急，我方也安排工程师加班加点，最终在最短的时间内将数据恢复出来。后续的数据迁移过程中由我方工程师和用户方工程师配合完成。