使用日志标签

在这种情况下，恢复分区对于修复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主机花费了一整晚，完成复制后，我开始再次尝试。

分享按钮