使用ESX troubleshooting恢復虛擬原始設備映射數據
從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!
重新啟動時，系統提醒進入調試模式以修復問題。
#p#
使用日志標簽
在這種情況下，恢復分區對于修復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主機花費了一整晚，完成復制后，我開始再次嘗試。
#p#
花三天解決了問題
由于這些文件現在都在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的文件（至少在我這樣的情況下）。
#p#
存儲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工具能找到這些。
【編輯推薦】
