×

虛擬機(jī)誤刪除的數(shù)據(jù)恢復(fù)方法

  • 作者:新網(wǎng)
  • 來源:新網(wǎng)
  • 瀏覽:100
  • 2018-05-11 15:02:39

因意外斷電,導(dǎo)致某臺虛擬機(jī)不能正常啟動(dòng),查看虛擬機(jī)的配置文件時(shí)發(fā)現(xiàn)此虛擬機(jī)的配置文件除了磁盤文件以外其他配置文件全部丟失。此時(shí)xxx-flat.vmdk磁盤文件和xxx-000001-delta.vmdk快照文件還存在。找VMware工程師診斷后,嘗試新建一個(gè)虛擬機(jī)來解決故 障,但發(fā)現(xiàn)ESXi存儲空間不足。因此就將故障虛擬機(jī)下的xxx-flat.vmdk磁盤文件刪除了,這時(shí)ESXi存儲就有200多G的剩余空間了,而后VMware工程師就重新建了一個(gè)40G的虛擬機(jī),并且分配了固定大小的虛擬磁盤。

   因意外斷電,導(dǎo)致某臺虛擬機(jī)不能正常啟動(dòng),查看虛擬機(jī)的配置文件時(shí)發(fā)現(xiàn)此虛擬機(jī)的配置文件除了磁盤文件以外其他配置文件全部丟失。此時(shí)xxx-flat.vmdk磁盤文件和xxx-000001-delta.vmdk快照文件還存在。找VMware工程師診斷后,嘗試新建一個(gè)虛擬機(jī)來解決故 障,但發(fā)現(xiàn)ESXi存儲空間不足。因此就將故障虛擬機(jī)下的xxx-flat.vmdk磁盤文件刪除了,這時(shí)ESXi存儲就有200多G的剩余空間了,而后VMware工程師就重新建了一個(gè)40G的虛擬機(jī),并且分配了固定大小的虛擬磁盤。

t01cdbbe36f69868006.jpg

  備份數(shù)據(jù)
  在VMware vSphere Client上將掛載的RD220i存儲中VMFS卷以正常方式卸載掉。然后將RD220i存儲上的VMFS卷通過網(wǎng)線的方式連接到備份服務(wù)器上,接著使用專業(yè)的工具將整個(gè)VMFS卷以扇區(qū)的方式鏡像到已準(zhǔn)備的備份空間上,以確保客戶的數(shù)據(jù)安全,之后的分析和恢復(fù)操作均在備份的數(shù)據(jù)上進(jìn)行。
  分析故障原因
  仔細(xì)分析VMFS卷的底層數(shù)據(jù)發(fā)現(xiàn),ESXi主機(jī)的突然斷電導(dǎo)致故障虛擬機(jī)目錄下的目錄項(xiàng)出現(xiàn)破壞,但是這種破壞不會(huì)影響虛擬機(jī)的重要數(shù)據(jù),只是破壞了文件的目錄項(xiàng)而已,可以通過人工修復(fù)即可解決。而人為刪除某個(gè)文件的話,則目錄項(xiàng)對應(yīng)的數(shù)據(jù)區(qū)索引會(huì)被清掉,也不會(huì)影響刪除文件的實(shí)際數(shù)據(jù)。這種情況可根據(jù)刪除虛擬磁盤文件中的文件系統(tǒng)以及虛擬磁盤中的文件類型在VMFS卷自由空間中進(jìn)行碎片匹配和合并,最終也可恢復(fù)刪除的虛擬磁盤文件。但是在上述的兩種情況之下又新建了一臺虛擬機(jī),并且分配了虛擬磁盤。經(jīng)過仔細(xì)分析發(fā)現(xiàn)分配的40G虛擬磁盤已經(jīng)全部清零了(在創(chuàng)建虛擬磁盤的時(shí)候會(huì)選擇創(chuàng)建磁盤的類型),也是這個(gè)新建的虛擬機(jī)所占用的磁盤空間全部被清零。 如果新虛擬磁盤占用了刪除虛擬機(jī)磁盤所釋放的空間,那么此部分空間將無法恢復(fù)的。
  1、實(shí)施方向一:恢復(fù)刪除的VMDK文件
  根據(jù)刪除虛擬磁盤文件中的文件系統(tǒng)以及虛擬磁盤中的文件類型在VMFS卷的自由空間中進(jìn)行碎片匹配和合并,最終恢復(fù)刪除的虛擬磁盤文件,再利用快照合并程序?qū)⒖煺瘴募突謴?fù)的虛擬磁盤文件合并成一個(gè)完整的虛擬磁盤文件,然后利用專業(yè)的文件系統(tǒng)解釋工具解釋虛擬磁盤文件中的所有文件。
  2、實(shí)施方向二:恢復(fù)MSSQL數(shù)據(jù)庫文件
  如果方向一實(shí)施的效果不太理想,接下來可根據(jù)SQL Server數(shù)據(jù)庫文件的結(jié)構(gòu),對VMFS卷自由空間中符合SQL Server頁結(jié)構(gòu)的數(shù)據(jù)區(qū)域進(jìn)行統(tǒng)計(jì)、分析和聚合,最終生成一個(gè)可以正常使用的.MDF格式的文件。
  3、實(shí)施方向三:恢復(fù)MSSQL數(shù)據(jù)庫備份文件
  由于數(shù)據(jù)庫每天都在做備份,雖然每天一次增量備份,15天一次全部備份。但是如果上述兩種方案實(shí)施過后還有一些數(shù)據(jù)庫無法恢復(fù)的話,則只能利用恢復(fù)備份文件來恢復(fù)數(shù)據(jù)庫了。根據(jù)掌握的備份文件.bak的結(jié)構(gòu),對VMFS卷自由空間中符合SQL Server備份文件結(jié)構(gòu)的數(shù)據(jù)區(qū)域進(jìn)行統(tǒng)計(jì)、分析和聚合,最終生成一個(gè)可以正常導(dǎo)入到SQL Server數(shù)據(jù)庫中.BAK格式的文件。
  1、方向一實(shí)施過程
  按照方向一的思路進(jìn)行底層分析,根據(jù)VMFS卷的結(jié)構(gòu)以及刪除虛擬磁盤的文件系統(tǒng)信息,在底層的自由空間中掃描符合刪除虛擬機(jī)磁盤的區(qū)域,并統(tǒng)計(jì)其數(shù)量和大小是否符合刪除虛擬磁盤的大小。再根據(jù)虛擬磁盤中的文件系統(tǒng)的信息將這些掃描到的碎片進(jìn)行排列組合,結(jié)果發(fā)現(xiàn)中間有好多碎片缺失,仔細(xì)再對這些缺失的碎片進(jìn)行重新掃描,發(fā)現(xiàn)這些碎片確實(shí)沒有找到。接著將掃描到的碎片安照虛擬磁盤原本的順序重組,對于沒有找到的碎片暫且留空。接下來利用虛擬磁盤快照程序?qū)⒅亟M好的父盤和快照盤進(jìn)行合并,生成一個(gè)新的虛擬磁盤。再用專業(yè)工具解釋虛擬磁盤中的文件系統(tǒng),因缺失好多數(shù)據(jù),文件系統(tǒng)解釋過程中報(bào)好多錯(cuò)誤,提示某些文件損壞。
  在解析完文件系統(tǒng)后發(fā)現(xiàn)沒有找到原始的數(shù)據(jù)庫文件,而宏橋備份和索菲備份這兩個(gè)目錄的目錄結(jié)構(gòu)正常。但是在嘗試將備份導(dǎo)入數(shù)據(jù)庫中時(shí),數(shù)據(jù)庫導(dǎo)入程序提示報(bào)錯(cuò)。
  方向二實(shí)施過程
  由于方向一中并沒有將原始的數(shù)據(jù)庫文件恢復(fù)出來,并且其中好多備份文件都無法正常使用。因此需采用第二套方案來恢復(fù)尚未恢復(fù)的數(shù)據(jù)庫文件。根據(jù)SQL Server數(shù)據(jù)庫的結(jié)構(gòu)去自由空間中找到數(shù)據(jù)庫的開始位置。在數(shù)據(jù)庫的結(jié)構(gòu)中,數(shù)據(jù)庫的第9個(gè)頁會(huì)記錄本數(shù)據(jù)庫的數(shù)據(jù)庫名。因此根據(jù)這個(gè)特征可以核對此數(shù)據(jù)庫的頭部頁是否是正在查找的。并且數(shù)據(jù)庫的每個(gè)頁中都會(huì)記錄數(shù)據(jù)庫頁編號以及文件號,所以根據(jù)這些特征編寫數(shù)據(jù)庫掃描程序,然后利用程序去底層掃描所有符合數(shù)據(jù)庫頁的數(shù)據(jù)碎片。接著將掃描出來的碎片按順序重組成一個(gè)完整MDF文件,再通過MDF校驗(yàn)程序檢測整個(gè)MDF文件是否完整。在整個(gè)校驗(yàn)過程中,只有cl_system3.dbf和erp42_jck.dbf因有部分碎片沒有找到外,其余數(shù)據(jù)庫均校驗(yàn)成功。
  cl_system3.dbf和erp42_jck.dbf因底層有很多碎片沒有找不到(初步懷疑可能被覆蓋),因此校驗(yàn)不通過。
  方向三實(shí)施過程
  由于上述兩個(gè)方向?qū)嵤┩旰?,并沒有將所有的數(shù)據(jù)庫文件全部恢復(fù)出來,還有cl_system3.dbf和erp42_jck.dbf這里個(gè)文件因缺失部分頁導(dǎo)致其無法正常使用。因此需要采用備份來恢復(fù)這兩個(gè)數(shù)據(jù)庫文件,但是在檢查完這兩個(gè)文件的備份后發(fā)現(xiàn)cl_system3.dbf的3月30號全部備份因備份機(jī)制故障導(dǎo)致沒有備份出來,而erp42_jck.dbf的3月份備份全部沒有,只有4月份的全部增量備份。
  由于erp42_jck.dbf文件中只缺失少量的頁,因此可以根據(jù)缺失的頁號在增量備份中查找,再將找到的頁補(bǔ)到erp42_jck.dbf文件中,這樣可以恢復(fù)一部分丟失的數(shù)據(jù)庫頁。最終補(bǔ)完后還是缺失部分頁,無法正常使用。但是可以通過自主開發(fā)的數(shù)據(jù)庫解析程序?qū)rp42_jck.dbf文件中用戶比較重要的幾十張表成功導(dǎo)出,并成功導(dǎo)入到新建的數(shù)據(jù)庫中。
  在本地服務(wù)器中搭建和原始環(huán)境一樣的數(shù)據(jù)庫環(huán)境(SQL Server 2008),由客戶通過Teamviewer遠(yuǎn)程工具連接到驗(yàn)證服務(wù)器,并安裝上層宏橋應(yīng)用軟件。再由客戶安排工程驗(yàn)證數(shù)據(jù)庫是否完整,經(jīng)過仔細(xì)的驗(yàn)證后,數(shù)據(jù)庫恢復(fù)基本沒問題。上層應(yīng)用可以正常運(yùn)行,數(shù)據(jù)記錄也都基本沒有缺失,數(shù)據(jù)恢復(fù)成功。
  由于客戶數(shù)據(jù)先是被突然斷電導(dǎo)致其部分文件丟失,接著人為刪掉了部分?jǐn)?shù)據(jù),并且又重新寫入部分?jǐn)?shù)據(jù),導(dǎo)致其存在數(shù)據(jù)覆蓋的可能性。最后又因數(shù)據(jù)庫的備份機(jī)制原因?qū)е虏糠謹(jǐn)?shù)據(jù)庫的備份數(shù)據(jù)沒有,因此整個(gè)恢復(fù)難度很大。由于對SQL Server數(shù)據(jù)庫底層結(jié)構(gòu)足夠了解,并且有處理過類似故障類型的經(jīng)驗(yàn)。所以整個(gè)恢復(fù)過程中還算比較順利。數(shù)據(jù)庫均正?;謴?fù),并且驗(yàn)證沒有問題,整個(gè)數(shù)據(jù)恢復(fù)成功。

免責(zé)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn)自行上傳,本網(wǎng)站不擁有所有權(quán),也不承認(rèn)相關(guān)法律責(zé)任。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容,請發(fā)送郵件至:operations@xinnet.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),本站將立刻刪除涉嫌侵權(quán)內(nèi)容。

免費(fèi)咨詢獲取折扣

Loading