EMC Isilon(OneFS)存储数据恢复方案【服务器数据恢复案例】
【科普Isilon的存儲(chǔ)結(jié)構(gòu)】
Isilon內(nèi)部使用的是分布式文件系統(tǒng)OneFS。在Isilon存儲(chǔ)集群里面每個(gè)節(jié)點(diǎn)均為單一OneFS文件系統(tǒng),所以Isilon在支持橫向擴(kuò)展的同時(shí)并不會(huì)影響數(shù)據(jù)正常使用。在存儲(chǔ)集群工作時(shí),所有節(jié)點(diǎn)提供相同的功能,節(jié)點(diǎn)與節(jié)點(diǎn)之前沒(méi)有主備之分。當(dāng)用戶(hù)往存儲(chǔ)集群中存儲(chǔ)文件時(shí),OneFS層會(huì)將文件分成128K的片段分別存到不同的節(jié)點(diǎn)中,而在節(jié)點(diǎn)層又會(huì)將128K的片段分成8K的小片段分別存到該節(jié)點(diǎn)的不同硬盤(pán)中。而用戶(hù)文件的Indoe信息、目錄項(xiàng)及數(shù)據(jù)MAP則會(huì)分別存儲(chǔ)在所有節(jié)點(diǎn)中,這樣可以確保用戶(hù)不管從那個(gè)節(jié)點(diǎn)都可以訪(fǎng)問(wèn)到所有數(shù)據(jù)。Isilon在初始化時(shí)會(huì)讓用戶(hù)選擇相應(yīng)的存儲(chǔ)冗余模式,不同的冗余模式所提供的數(shù)據(jù)安全級(jí)別也不一樣(默認(rèn)3個(gè)節(jié)點(diǎn)采用N+2:1模式)。
【存儲(chǔ)數(shù)據(jù)恢復(fù)故障描述】
某公司管理員由于誤操作將服務(wù)器中包括MSSQL數(shù)據(jù)庫(kù),以及大量的MP4、ASF和TS類(lèi)型的視頻文件等重要數(shù)據(jù)刪除。需要進(jìn)行數(shù)據(jù)恢復(fù)的這臺(tái)服務(wù)器整體存儲(chǔ)架構(gòu)采用EMC高端網(wǎng)絡(luò)NAS(Isilon S200),節(jié)點(diǎn)數(shù)量為3個(gè),每個(gè)節(jié)點(diǎn)配置12塊3T STAT硬盤(pán),無(wú)SSD。需要進(jìn)行數(shù)據(jù)恢復(fù)的數(shù)據(jù)包括vmware虛擬機(jī)(WEB服務(wù)器)和視頻文件,虛擬機(jī)通過(guò)NFS協(xié)議共享到ESX主機(jī),視頻文件通過(guò)CIFS協(xié)議共享給虛擬機(jī)(WEB服務(wù)器)。NFS共享的所有數(shù)據(jù)(也就是所有虛擬機(jī))被刪除而CIFS共享的數(shù)據(jù)則沒(méi)有被刪除。
【備份服務(wù)器數(shù)據(jù)】
因考慮到數(shù)據(jù)安全性,避免對(duì)數(shù)據(jù)造成二次破壞,需對(duì)所有硬盤(pán)進(jìn)行全部備份。但是由于磁盤(pán)數(shù)量太多(單節(jié)點(diǎn)12塊盤(pán),3個(gè)節(jié)點(diǎn)36塊盤(pán)),且單盤(pán)容量太大(單盤(pán)3TB,一共108TB),因此備份周期會(huì)較長(zhǎng)。最終客戶(hù)決定,只對(duì)存儲(chǔ)中現(xiàn)有數(shù)據(jù)進(jìn)行備份,并且由數(shù)據(jù)恢復(fù)公司備份一次,客戶(hù)再備份一次,以確保現(xiàn)有數(shù)據(jù)安全。
【服務(wù)器數(shù)據(jù)分析】
服務(wù)器數(shù)據(jù)備份完成后在Isilon的web管理界面中將Isilon正常關(guān)機(jī)。再將所有節(jié)點(diǎn)上的所有硬盤(pán)貼上標(biāo)簽,并依次取出再放到數(shù)據(jù)恢復(fù)平臺(tái)中,開(kāi)始分析所有硬盤(pán)中的數(shù)據(jù)。
由于客戶(hù)數(shù)據(jù)是被刪除了,因此不用過(guò)多考慮存儲(chǔ)的冗余級(jí)別,重點(diǎn)需要分析文件刪除后,文件Indoe及數(shù)據(jù)MAP是否發(fā)生變化。刪除的虛擬磁盤(pán)文件都在64G或以上,并且存儲(chǔ)中沒(méi)有其他類(lèi)型的大文件。編寫(xiě)掃描所有文件Indoe的程序,將文件大小符合64G或以上的Indoe都掃描出來(lái)。再仔細(xì)分析掃描出來(lái)的Indoe,發(fā)現(xiàn)Indoe中記錄的數(shù)據(jù)MAP位置,其index指向的內(nèi)容已不再是正常數(shù)據(jù),并且所有節(jié)點(diǎn)上的Indoe均是同樣的情況。再仔細(xì)分析Inode,發(fā)現(xiàn)大文件的數(shù)據(jù)MAP會(huì)有多層(樹(shù)結(jié)構(gòu)),并且數(shù)據(jù)MAP中會(huì)記錄文件的唯一ID,因此可以嘗試找到文件最底層的數(shù)據(jù)MAP。抱著僥幸心理對(duì)文件最底層的數(shù)據(jù)MAP做遍歷跟蹤操作,發(fā)現(xiàn)最低層的數(shù)據(jù)MAP果然還在。
【數(shù)據(jù)恢復(fù)過(guò)程】
從文件的Inode中取出文件的唯一ID,然后對(duì)所有符合該ID的數(shù)據(jù)MAP做聚合。并根據(jù)數(shù)據(jù)MAP中的VCN號(hào)做排序,發(fā)現(xiàn)每個(gè)文件的前17088項(xiàng)數(shù)據(jù)MAP都不存在,也就意味著每個(gè)文件的前17088項(xiàng)數(shù)據(jù)是真的沒(méi)辦法恢復(fù)了(心情一下跌落低谷)。
仔細(xì)換算了一下發(fā)現(xiàn)丟失的數(shù)據(jù)MAP項(xiàng)總共才包含不到1G的數(shù)據(jù),而刪除的文件全是虛擬機(jī)的vmdk文件,里面都是NTFS的文件系統(tǒng),而NTFS文件系統(tǒng)的MFT基本都在3G的位置,也就是只需要在每個(gè)vmdk文件的頭部手動(dòng)偽造一個(gè)MBR和DBR就可以解釋vmdk里面的數(shù)據(jù)了。對(duì)掃描到的數(shù)據(jù)MAP做解釋,并根據(jù)VCN號(hào)的順序?qū)С鰯?shù)據(jù),沒(méi)有MAP的情況保留為零。
經(jīng)過(guò)不斷的測(cè)試,先導(dǎo)出一個(gè)vmdk文件來(lái)看看。結(jié)果令我大吃一驚,導(dǎo)出的vmdk文件比實(shí)際情況要小,并且vmdk中MFT的位置也與自身描述不符。手動(dòng)隨機(jī)驗(yàn)證了幾個(gè)MPA發(fā)現(xiàn)都能指向數(shù)據(jù)區(qū),而程序解釋MAP的方式也都沒(méi)有問(wèn)題。所以猜測(cè)到可能為文件稀疏!
將代碼進(jìn)行部分調(diào)整后重新導(dǎo)出剛才的vmdk,這次vmdk大小符合實(shí)際大小,且MFT的位置也在相應(yīng)位置。手工偽造一個(gè)MBR,分區(qū)表以及DBR,再用文件系統(tǒng)解釋工具(自用工具)成功解釋其文件系統(tǒng),導(dǎo)出vmdk里面的數(shù)據(jù)庫(kù)及視頻文件。
在驗(yàn)證了此vmdk中的數(shù)據(jù)庫(kù)及視頻文件沒(méi)問(wèn)題后,批量導(dǎo)出所有重要的vmdk文件,再手工一個(gè)一個(gè)的去修改每個(gè)vmdk文件。
【數(shù)據(jù)驗(yàn)收】
將客戶(hù)所有重要的數(shù)據(jù)恢復(fù)完成后,由客戶(hù)方安排工程師對(duì)恢復(fù)的所有數(shù)據(jù)做完整性及準(zhǔn)確性檢測(cè),數(shù)據(jù)最終確定完全沒(méi)有問(wèn)題,數(shù)據(jù)恢復(fù)成功。
總結(jié)
以上是生活随笔為你收集整理的EMC Isilon(OneFS)存储数据恢复方案【服务器数据恢复案例】的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: Nginx反向代理与正向代理配置
- 下一篇: 文件修复软件winhex