使用ESX troubleshooting恢復(fù)虛擬原始設(shè)備映射數(shù)據(jù)
從ESX邏輯單元號(hào)（LUN）刪除分區(qū)之后，我們的虛擬化專(zhuān)家Edward Haletky必須恢復(fù)對(duì)虛擬機(jī)文件系統(tǒng)（VMFS）的訪問(wèn)以便訪問(wèn)數(shù)據(jù)。在這一系列的第一篇文章中，他討論了如何恢復(fù)對(duì)VMFS的訪問(wèn)。不過(guò)我們的專(zhuān)家立即發(fā)現(xiàn)他不能以同樣的方式恢復(fù)虛擬原始設(shè)備映射（RDM），這也意味著可能丟失大量的可用歷史數(shù)據(jù)。下面的文章將解決這個(gè)問(wèn)題。
第一篇文章討論了恢復(fù)對(duì)虛擬機(jī)文件系統(tǒng)（VMFS）的訪問(wèn)，Vizioncore vRanger Pro幫助我恢復(fù)了VMFS要使用的必要分區(qū)。我也試著用同樣的方法恢復(fù)原始設(shè)備映射（RDM），但是出現(xiàn)“Cannot create file”這樣的錯(cuò)誤信息。
接下來(lái)，我嘗試使用Vizioncore的vcbRestore文件將鏡像手動(dòng)恢復(fù)到ESX主機(jī)。由于服務(wù)器信息塊（SMB/CIFS）不能正常工作也失敗了。我的方法是使用下面的命令恢復(fù)所有文件：
/tmp/vcbrestore -D -I ./VM_4.tvzc -O /dev/stdout | tar -xvf -
不幸的是這也不起作用。（偶然發(fā)現(xiàn)這時(shí)可以將vcbRestore文件移動(dòng)到不同的邏輯單元號(hào)，并嘗試用這樣的方式執(zhí)行恢復(fù)，不過(guò)我沒(méi)有足夠的LUN空間。）
接下來(lái)，我嘗試從ESX主機(jī)的服務(wù)控制臺(tái)重新創(chuàng)建Linux logical volume manager (LVM) 2文件系統(tǒng)。但那樣的努力在我重新啟動(dòng)虛擬機(jī)時(shí)也失敗了：
# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel.
更改只保留在內(nèi)存里，除非你決定寫(xiě)入它們。當(dāng)然，先前的內(nèi)容不能恢復(fù)。
The number of cylinders for this disk is set to 39162.
這樣做沒(méi)錯(cuò)，但這比1024大，并且在某些設(shè)置下可能會(huì)導(dǎo)致兩個(gè)方面的問(wèn)題：在啟動(dòng)時(shí)間運(yùn)行軟件（如LILO的舊版本（或者從其他操作系統(tǒng)（如DOS FDISK和OS/2 FDISK）啟動(dòng)或劃分軟件。
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!
重新啟動(dòng)時(shí)，系統(tǒng)提醒進(jìn)入調(diào)試模式以修復(fù)問(wèn)題。
#p#
使用日志標(biāo)簽
在這種情況下，恢復(fù)分區(qū)對(duì)于修復(fù)RDM問(wèn)題來(lái)說(shuō)遠(yuǎn)遠(yuǎn)不夠。然后我以根用戶身份登錄，使用在Recovering an LVM physical volume里的步驟恢復(fù)LVM卷。不過(guò)這些步驟也不盡管用，因?yàn)檎f(shuō)明要求我首先移除分區(qū)，這是錯(cuò)誤的。
最終我使用了與日志標(biāo)簽相類(lèi)似的步驟，只不過(guò)我用的是/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
恢復(fù)LVM物理卷的這種嘗試應(yīng)該使LVM2卷?yè)碛幸粋€(gè)文件系統(tǒng)，但是失敗了。正如我們?cè)谏弦黄恼轮袑W(xué)到的，如果一個(gè)正規(guī)的步驟得到不正常的結(jié)果，那么就存在錯(cuò)誤。
使用手動(dòng)恢復(fù)
我手動(dòng)恢復(fù)的第二次嘗試是使用Microsoft Windows VMware Consolidated Backup (VCB)代理服務(wù)器（它也像我的Vizioncore vRanger Pro知識(shí)庫(kù)）。在這次恢復(fù)中，我嘗試使用來(lái)自vcbRestore的另一款工具FileZipper。如先前一樣，恢復(fù)失敗。
然后我試著從GNU Win32知識(shí)庫(kù)安裝bsdtar。同樣失敗了。這時(shí)，我開(kāi)始思索這個(gè)問(wèn)題不在于VMware ESX或vRanger Pro工具，而在于NT文件系統(tǒng)（NTFS）。為確定NTFS是否存在問(wèn)題，我在當(dāng)作桌面的Linux機(jī)器上找到了空間，并使用CIFS啟動(dòng)和安全復(fù)制（SCP）復(fù)制文件從VCB Proxy啟動(dòng)備份地點(diǎn)到Linux系統(tǒng)。
# mkdir /mnt/backup
# mount -t cifs -o username=******* //vcbproxy/backup /mnt/backup
# scp /mnt/backup/VM_4.tvzc* /iet
我使用scp而不是其他工具，因?yàn)樵贓SX主機(jī)之間復(fù)制虛擬機(jī)磁盤(pán)文件時(shí)，scp是正確的選擇。在處理稀少文件方面，它比傳統(tǒng)的cp命令好用。
復(fù)制文件到Linux主機(jī)花費(fèi)了一整晚，完成復(fù)制后，我開(kāi)始再次嘗試。
#p#
花三天解決了問(wèn)題
由于這些文件現(xiàn)在都在Linux主機(jī)上，我再次使用vcbrestore命令就成功了。
/tmp/vcbrestore -D -I ./VM_4.tvzc -O /dev/stdout | tar -xvf -
由于最后一次嘗試成功了，現(xiàn)在我已經(jīng)可以成功復(fù)制導(dǎo)致問(wèn)題的虛擬機(jī)的flat.vmdk和-rdm.vmdk文件，我知道先前失敗的原因在于NTFS和SMB/CIFS。不過(guò)，由于虛擬RDM恢復(fù)成了VMDK文件，為了使用虛擬機(jī)，對(duì)-rdm.vmdk元數(shù)據(jù)作一些小改動(dòng)是必要的。我必須更改VM_1.vmdk元數(shù)據(jù)文件里的兩行。
createType="vmfsRawDeviceMap"
更改為
createType="vmfs"
還有
RW 584888320 VMFSRDM "VM_1-rdm.vmdk"
更改為
RW 584888320 VMFS "VM_1-rdm.vmdk"
我現(xiàn)在可以在VMware Workstation v6.5或VMware Server v2里運(yùn)行虛擬機(jī)了。我測(cè)試了一些恢復(fù)理論。虛擬機(jī)在VMware Server v2里運(yùn)行得很好。它不能在ESX里運(yùn)行，因?yàn)閂MFS不能處理大于256GB的文件。
為什么vRangerPro失敗了？
在過(guò)程中的這個(gè)階段，我最終明白了Vizioncore vRangerPro是如何備份虛擬RDM的。非常感謝Vizioncore的一位高級(jí)工程師，我也開(kāi)始明白了vRangerPro的恢復(fù)方法。很明顯，虛擬RDM比256GB大得多，因此我不能將其作為VMDK存儲(chǔ)在VMFS。為什么？因?yàn)楫?dāng)我設(shè)置VMFS，我不允許它處理較大的文件。這就是為什么使用Vizioncore vRangerPro嘗試恢復(fù)的時(shí)候失敗了。vRanger Pro將所有RDM作為VMDK存儲(chǔ)，這需要你的LUN上有足夠的空間，并且LUN支持大于256GB的文件（至少在我這樣的情況下）。
#p#
存儲(chǔ)LVM和ext3文件系統(tǒng)
嘗試存儲(chǔ)LVM和Linux ext3文件系統(tǒng)是令人沮喪的。在研究Web服務(wù)后，我發(fā)現(xiàn)一個(gè)新工具，很容易放進(jìn)去，不能做它所說(shuō)的事。
然后我開(kāi)始刷新虛擬機(jī)的-flat.vmdk文件。我嘗試了其他故障檢修方法都沒(méi)用。更多的研究和更多的嘗試讓我回到了原點(diǎn)。
同時(shí)，我尋求成功恢復(fù)的方法變得愈加重要，我現(xiàn)在需要給用戶提供一些存檔數(shù)據(jù)。時(shí)間越來(lái)越緊迫。
加速解決問(wèn)題
有時(shí)，睡一個(gè)好覺(jué)醒來(lái)對(duì)問(wèn)題就有了重新的認(rèn)識(shí)。我醒來(lái)后就考慮到使用在創(chuàng)建備份時(shí)所保留的內(nèi)存鏡像來(lái)訪問(wèn)內(nèi)存的內(nèi)核分區(qū)和文件系統(tǒng)結(jié)構(gòu)。
下面是步驟：
我嘗試使用.vmss文件里的內(nèi)容將.vmsn文件替換成.vmss文件，并重新啟動(dòng)虛擬機(jī)以嘗試復(fù)快照。（注，當(dāng)使用Vizioncore vRangerPro作為.vmsn快照時(shí)，.vmss文件是備份的一部分。）這種嘗試失敗了，也沒(méi)有報(bào)道錯(cuò)誤。
接下來(lái)，我試著使用.vmss文件作為虛擬機(jī)的暫停文件。這不起作用。我一直得到msg.checkpoint.resume.fail錯(cuò)誤，沒(méi)有任何解釋。上網(wǎng)搜索了一下，說(shuō)可能是.vmsd文件的問(wèn)題，因此我移除了現(xiàn)在沒(méi)使用的快照目錄文件。這也不起作用。
我發(fā)送郵件給Vizioncore公司，看看他們是否有辦法使用這個(gè)鏡像。不過(guò)幾個(gè)小時(shí)后，我有沒(méi)收到任何回復(fù)。
我也聯(lián)系了我的一些朋友，他們說(shuō)嘗試下FTK-Imager。FTK-Imager找到LVM數(shù)據(jù)，但是對(duì)卷不起作用。這是Forensics公司一個(gè)很好的工具，不過(guò)對(duì)于恢復(fù)不起作用（它只與分區(qū)完整的VMDK工作）。
Nucleus Kernel Linux節(jié)約時(shí)間
在我對(duì)Linux ext3恢復(fù)的研究中，我重新找到了Nucleus Kernel Linux。Nucleus運(yùn)行在Windows上，因此當(dāng)我第一次碰見(jiàn)它時(shí)，我忽略了它。不過(guò)由于我現(xiàn)在在翻箱倒柜地找恢復(fù)方法，所以我決定嘗試它。Nucleus不直接與虛擬機(jī)磁盤(pán)文件工作，因此我在Windows XP SP3虛擬機(jī)上安裝它。在啟動(dòng)之前，我將虛擬RDM附屬到虛擬機(jī)。
經(jīng)過(guò)了好些天的實(shí)驗(yàn)和錯(cuò)誤，我最終解決了問(wèn)題。Nucleus發(fā)現(xiàn)了缺失的分區(qū)，然后在分區(qū)上發(fā)現(xiàn)了文件。
在購(gòu)買(mǎi)和運(yùn)行Nucleus Kernel Linux工具后，我從虛擬RDM復(fù)制數(shù)據(jù)到Linux系統(tǒng)很輕松。完成后，我使用合適的文件系統(tǒng)重新創(chuàng)建虛擬RDM，并恢復(fù)缺失的數(shù)據(jù)。（為了以防萬(wàn)一，我以VMDK格式保留了虛擬RDM的備份副本）。
在我恢復(fù)VMFS和RDM的過(guò)程嘗試中，我學(xué)到了幾點(diǎn)。首先，不要漏掉出現(xiàn)錯(cuò)誤的第一條線索——如果你突然發(fā)現(xiàn)看見(jiàn)了更多的分區(qū)，停下考慮這是為什么并不要立即刪除它們。記住，啟動(dòng)的虛擬機(jī)維持它們的分區(qū)，你應(yīng)該立即備份，不過(guò)虛擬RDM讀原始磁盤(pán)，而不是核心數(shù)據(jù)結(jié)構(gòu)，因此使用一些文件副本形式備份虛擬RDM。
如果你想恢復(fù)虛擬RDM，需要能處理最終VMDK文件大小的VMFS，我的ESX上沒(méi)有這么大的VMFS。不過(guò)我的Linux系統(tǒng)上有足夠大的空間。最后，恢復(fù)缺失了分區(qū)表的VMFS是瑣碎的，但是在LVM2分區(qū)里恢復(fù)包括Linux ext3文件系統(tǒng)的虛擬或物理RDM也同樣瑣碎。幸運(yùn)的是Nucleus Kernel Linux工具能找到這些。
【編輯推薦】
