从ESX逻辑单元号（LUN）删除分区之后，我们的虚拟化专家Edward Haletky必须恢复对虚拟机文件系统（VMFS）的访问以便访问数据。在这一系列的第一篇文章中，他讨论了如何恢复对VMFS的访问。不过我们的专家立即发现他不能以同样的方式恢复虚拟原始设备映射（RDM），这也意味着可能丢失大量的可用历史数据。下面的文章将解决这个问题。

　　第一篇文章讨论了恢复对虚拟机文件系统（VMFS）的访问，Vizioncore vRanger Pro帮助我恢复了VMFS要使用的必要分区。我也试着用同样的方法恢复原始设备映射（RDM），但是出现“Cannot create file”这样的错误信息。

　　接下来，我尝试使用Vizioncore的vcbRestore文件将镜像手动恢复到ESX主机。由于服务器信息块（SMB/CIFS）不能正常工作也失败了。我的方法是使用下面的命令恢复所有文件：

　　/tmp/vcbrestore -D -I ./VM_4.tvzc -O /dev/stdout | tar -xvf -

　　不幸的是这也不起作用。（偶然发现这时可以将vcbRestore文件移动到不同的逻辑单元号，并尝试用这样的方式执行恢复，不过我没有足够的LUN空间。）

　　接下来，我尝试从ESX主机的服务控制台重新创建Linux logical volume manager (LVM) 2文件系统。但那样的努力在我重新启动虚拟机时也失败了：

# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel.

　　更改只保留在内存里，除非你决定写入它们。当然，先前的内容不能恢复。

The number of cylinders for this disk is set to 39162.

　　这样做没错，但这比1024大，并且在某些设置下可能会导致两个方面的问题：在启动时间运行软件（如LILO的旧版本（或者从其他操作系统（如DOS FDISK和OS/2 FDISK）启动或划分软件。

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-39162, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-39162, default 39162):
Using default value 39162
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fb
Changed system type of partition 1 to fb (Unknown)
Command (m for help): x
Expert command (m for help): b
Partition number (1-4): 1
New beginning of data (63-629137529, default 63): 128
Expert command (m for help): w
The partition table has been altered!

　　重新启动时，系统提醒进入调试模式以修复问题。

　　使用日志标签

　　在这种情况下，恢复分区对于修复RDM问题来说远远不够。然后我以根用户身份登录，使用在Recovering an LVM physical volume里的步骤恢复LVM卷。不过这些步骤也不尽管用，因为说明要求我首先移除分区，这是错误的。

　　最终我使用了与日志标签相类似的步骤，只不过我用的是/dev/sdb1 instead of /dev/sdb。

# mount -o remount,rw /
# cp /etc/lvm/backup/VolGroup03 /tmp
# pvcreate -u fvrw-GHKde-hgbf43-JKBdew-rvKLJc-cewbn /dev/sdb1
Physical volume "/dev/sdc" successfully created
# vgcreate -v VolGroup03 /dev/sdb1
Wiping cache of LVM-capable devices
Adding physical volume '/dev/sdb1' to volume group 'VolGrou03'
Archiving volume group "VolGroup03" metadata (seqno 0).
Creating volume group backup "/etc/lvm/backup/VolGroup03" (seqno 1).
Volume group "VolGroup03" successfully created
# cp /tmp/VolGroup03 /etc/lvm/backup
# vgcfgrestore VolGroup03
Restored volume group VolGroup03
# vgchange -ay
2 logical volume(s) in volume group "VolGrou03" now active

　　恢复LVM物理卷的这种尝试应该使LVM2卷拥有一个文件系统，但是失败了。正如我们在上一篇文章中学到的，如果一个正规的步骤得到不正常的结果，那么就存在错误。

　　使用手动恢复

　　我手动恢复的第二次尝试是使用Microsoft Windows VMware Consolidated Backup (VCB)代理服务器（它也像我的Vizioncore vRanger Pro知识库）。在这次恢复中，我尝试使用来自vcbRestore的另一款工具FileZipper。如先前一样，恢复失败。

　　然后我试着从GNU Win32知识库安装bsdtar。同样失败了。这时，我开始思索这个问题不在于VMware ESX或vRanger Pro工具，而在于NT文件系统（NTFS）。为确定NTFS是否存在问题，我在当作桌面的Linux机器上找到了空间，并使用CIFS启动和安全复制（SCP）复制文件从VCB Proxy启动备份地点到Linux系统。

# mkdir /mnt/backup
# mount -t cifs -o username=******* //vcbproxy/backup /mnt/backup
# scp /mnt/backup/VM_4.tvzc* /iet

　　我使用scp而不是其他工具，因为在ESX主机之间复制虚拟机磁盘文件时，scp是正确的选择。在处理稀少文件方面，它比传统的cp命令好用。

　　复制文件到Linux主机花费了一整晚，完成复制后，我开始再次尝试。

　　花三天解决了问题

　　由于这些文件现在都在Linux主机上，我再次使用vcbrestore命令就成功了。

/tmp/vcbrestore -D -I ./VM_4.tvzc -O /dev/stdout | tar -xvf -

　　由于最后一次尝试成功了，现在我已经可以成功复制导致问题的虚拟机的flat.vmdk和-rdm.vmdk文件，我知道先前失败的原因在于NTFS和SMB/CIFS。不过，由于虚拟RDM恢复成了VMDK文件，为了使用虚拟机，对-rdm.vmdk元数据作一些小改动是必要的。我必须更改VM_1.vmdk元数据文件里的两行。

createType="vmfsRawDeviceMap"
更改为
createType="vmfs"
还有
RW 584888320 VMFSRDM "VM_1-rdm.vmdk"
更改为
RW 584888320 VMFS "VM_1-rdm.vmdk"

　　我现在可以在VMware Workstation v6.5或VMware Server v2里运行虚拟机了。我测试了一些恢复理论。虚拟机在VMware Server v2里运行得很好。它不能在ESX里运行，因为VMFS不能处理大于256GB的文件。

　　为什么vRangerPro失败了？

　　在过程中的这个阶段，我最终明白了Vizioncore vRangerPro是如何备份虚拟RDM的。非常感谢Vizioncore的一位高级工程师，我也开始明白了vRangerPro的恢复方法。很明显，虚拟RDM比256GB大得多，因此我不能将其作为VMDK存储在VMFS。为什么？因为当我设置VMFS，我不允许它处理较大的文件。这就是为什么使用Vizioncore vRangerPro尝试恢复的时候失败了。vRanger Pro将所有RDM作为VMDK存储，这需要你的LUN上有足够的空间，并且LUN支持大于256GB的文件（至少在我这样的情况下）。

　　存储LVM和ext3文件系统

　　尝试存储LVM和Linux ext3文件系统是令人沮丧的。在研究Web服务后，我发现一个新工具，很容易放进去，不能做它所说的事。

　　然后我开始刷新虚拟机的-flat.vmdk文件。我尝试了其他故障检修方法都没用。更多的研究和更多的尝试让我回到了原点。

　　同时，我寻求成功恢复的方法变得愈加重要，我现在需要给用户提供一些存档数据。时间越来越紧迫。

　　加速解决问题

　　有时，睡一个好觉醒来对问题就有了重新的认识。我醒来后就考虑到使用在创建备份时所保留的内存镜像来访问内存的内核分区和文件系统结构。

　　下面是步骤：

• 我尝试使用.vmss文件里的内容将.vmsn文件替换成.vmss文件，并重新启动虚拟机以尝试复快照。（注，当使用Vizioncore vRangerPro作为.vmsn快照时，.vmss文件是备份的一部分。）这种尝试失败了，也没有报道错误。
• 接下来，我试着使用.vmss文件作为虚拟机的暂停文件。这不起作用。我一直得到msg.checkpoint.resume.fail错误，没有任何解释。上网搜索了一下，说可能是.vmsd文件的问题，因此我移除了现在没使用的快照目录文件。这也不起作用。
• 我发送邮件给Vizioncore公司，看看他们是否有办法使用这个镜像。不过几个小时后，我有没收到任何回复。
• 我也联系了我的一些朋友，他们说尝试下FTK-Imager。FTK-Imager找到LVM数据，但是对卷不起作用。这是Forensics公司一个很好的工具，不过对于恢复不起作用（它只与分区完整的VMDK工作）。

　　Nucleus Kernel Linux节约时间

　　在我对Linux ext3恢复的研究中，我重新找到了Nucleus Kernel Linux。Nucleus运行在Windows上，因此当我第一次碰见它时，我忽略了它。不过由于我现在在翻箱倒柜地找恢复方法，所以我决定尝试它。Nucleus不直接与虚拟机磁盘文件工作，因此我在Windows XP SP3虚拟机上安装它。在启动之前，我将虚拟RDM附属到虚拟机。

　　经过了好些天的实验和错误，我最终解决了问题。Nucleus发现了缺失的分区，然后在分区上发现了文件。

　　在购买和运行Nucleus Kernel Linux工具后，我从虚拟RDM复制数据到Linux系统很轻松。完成后，我使用合适的文件系统重新创建虚拟RDM，并恢复缺失的数据。（为了以防万一，我以VMDK格式保留了虚拟RDM的备份副本）。

　　在我恢复VMFS和RDM的过程尝试中，我学到了几点。首先，不要漏掉出现错误的第一条线索——如果你突然发现看见了更多的分区，停下考虑这是为什么并不要立即删除它们。记住，启动的虚拟机维持它们的分区，你应该立即备份，不过虚拟RDM读原始磁盘，而不是核心数据结构，因此使用一些文件副本形式备份虚拟RDM。

　　如果你想恢复虚拟RDM，需要能处理最终VMDK文件大小的VMFS，我的ESX上没有这么大的VMFS。不过我的Linux系统上有足够大的空间。最后，恢复缺失了分区表的VMFS是琐碎的，但是在LVM2分区里恢复包括Linux ext3文件系统的虚拟或物理RDM也同样琐碎。幸运的是Nucleus Kernel Linux工具能找到这些。