【儲存資料恢復案例】Netapp誤操作刪除lun的資料恢復
環境:
儲存NETAPP
型號FAS3220
硬碟600G SAS 520位元組硬碟 72塊
共2個機頭,一個擴充套件櫃,共3組raid
故障:
誤操作刪除10個1T lun和1個5T lun
資料恢復流程:
為防止資料恢復過程中由於誤操作對原始磁碟造成二次破壞,首先要為每塊磁碟做完全映象。此後所有恢復操作都在映象盤上進行, 杜絕對原始磁碟資料造成破壞。
1、經過北亞資料恢復工程師討論後,最終出具資料恢復方案
第一步,分析盤序和LVM的組成方式;
第二步,掃描硬碟內的所有節點(一般只掃描“MBFI”,即使用者節點)
第三步,在節點掃描結果中找到檔案大小符合需求的節點並提取此節點uid相同,事務號最大的作為索引根;
第四步,根據索引根內的第一級資料指標提取本檔案的所有直接資料指標(需要參考節點中0x03位置的MAP深度,為0x00時直接從節點內提取資料,0x01時需要提取一次MAP,0x02時需要提取兩次MAP......)。在指標提取完畢後開始提取檔案資料。
2、分析超級塊
在盤頭位置找到超級塊
從超級塊中得到磁碟組名字,磁碟組的邏輯起始塊號,總塊數,磁碟組中raid的編號
netapp超級塊
3、去除校驗盤
每個資料塊佔8個扇區,資料塊後附加64位元組資料塊描述資訊。根據這些資訊可以判斷出哪些磁碟是校驗盤(提取資料時校驗盤需剔除)
0x10:6位元組為aggr_data塊號
如果0x10處為FFFF表示校驗塊
校驗塊描述資訊樣例
4、aggr盤序分析
盤序分析時主要依據每塊磁碟8號扇區的磁碟資訊以及磁碟末尾的RAID盤序表確定盤序。首先要確定各個磁碟所屬aggr組,然後再判斷組內盤序。資料指標跳轉時不考慮校驗盤,所以只取得資料盤的盤序即可。
aggr_raid(磁碟靠近尾部) 根據10H處的VCN塊號判斷磁碟組內各盤的順序
netapp盤序表
5、節點及節點頭部資訊
Netapp的節點分佈在數量眾多的資料塊內,在資料塊內又被統一組織為節點組。每個節點組的前64位元組記錄一些系統資料,之後用192位元組為一項記錄各個檔案節點。根據使用者級別可分為兩類:“MBFP”系統檔案節點和“MBFI”使用者檔案節點,在資料恢復時一般只取MBFI節點組即可。
netapp節點樣例圖
頭部資訊64位元組
解析如下:(此頭部為資料檔案的節點檔案塊頭部,大小為64位元組)
標誌,常量(“MBFP”為元檔案的節點標誌,“MBFI”為使用者檔案的節點標誌)
根據更新序列值獲取到最新節點
解析節點中節點型別,邏輯塊號,檔案數量,檔案大小,所佔塊數量,及資料指標
獲取節點在節點檔案中的邏輯塊號,從0開始計數
6、獲取目錄項,並根據其節點編號,找到對應節點
編寫資料提取程式
資料提取程式按照功能分為3步,分別為節點掃描、資訊錄入和資料提取。
1、掃描節點資訊
節點掃描類
節點掃描程式完整流程
在迴圈掃描完畢之後會將所有掃描到的MBFP、MBFI和DOC資料塊分別寫入到三個檔案內,用於後續處理。
2、將節點資訊匯入到資料庫
此模組主要負責將ScanNode掃描得到的MBFI和MBFP、Dir存入資料庫以備後續使用。
以下是流程:
MBFI匯入資料庫整體流程
函式執行完畢後可以檢視資料庫得到如下資訊:
節點匯入資訊
Netapp在更改inode節點時不會直接覆蓋而是重新分配inode進行寫入。單個檔案的節點node_uid唯一不變,mbfi_usn會隨著節點的變化而增大(正常情況下提取某個檔案時使用usn最大的節點)。一般情況下儲存劃分出的單個節點會作為LUN對映到伺服器使用,根據file_size可以確定這個檔案的大小,按照檔案大小分組後再選取usn最大值的節點,跳轉到MBFI檔案的offset值偏移位置,取出節點。
節點樣例
3、提取檔案
在獲取到要提取的檔案的Node之後,開始提取塊裝置檔案。
程式需要讀取配置檔案:
初始化完畢後,開始提取檔案的各級MAP,在本次提取過程中檔案大小均大於1T,MAP層級為4,所以需要提取4次。第一級MAP預設只佔用1個塊,所以在程式內直接提取,後三級MAP在GetAllMap函式內進行提取。透過塊號計算資料塊位置時,由於NetApp使用JBOD組織LVM,直接用塊號除以每塊磁碟上的塊數可得到當前塊所在的磁碟序號(計算機整數除法,丟棄小數邠);再使用塊號取餘塊數,得到資料塊在此磁碟上的物理塊號,物理塊號乘以塊大小,得到資料塊偏移位置。
資料庫檢測
搭建小機環境,安裝oracle資料庫,檢測資料庫檔案和備份檔案。
1、檢測資料庫檔案
使用提取出的資料庫檔案啟動資料庫,啟動失敗
經檢測該資料庫檔案存在壞塊,無法使用
2、檢測資料庫備份檔案
由於客戶設定的資料庫備份機制,每個資料庫都存在多個備份。
因此先篩選出最新的資料庫備份檔案,使用篩選出的備份檔案還原資料庫,經過一一嘗試,篩選出最新的可用的資料庫備份,還原資料庫環境,由客戶進行驗證。
驗證及資料移交
對恢復完成的資料庫進行驗證,資料庫中有少量的資料缺失,缺失量在可接受的範圍內。
經過3天左右的驗證,對資料庫恢復確認無誤,此次資料恢復工作圓滿成功。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31380569/viewspace-2846004/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【儲存資料恢復】NetApp儲存誤刪除的資料恢復案例資料恢復APP
- 【儲存資料恢復】NetApp儲存誤刪資料夾的資料恢復案例資料恢復APP
- 【伺服器資料恢復】NetApp儲存誤刪除的資料恢復案例伺服器資料恢復APP
- 【伺服器資料恢復】NetApp儲存中lun被誤刪除的資料恢復過程伺服器資料恢復APP
- 【儲存資料恢復】HP EVA儲存誤刪除VDISK的資料恢復案例資料恢復
- 【NetApp資料恢復案例】針對NetApp誤刪除資料的恢復APP資料恢復
- Netapp 資料恢復案例;誤刪除所有lun解決方案APP資料恢復
- 【伺服器資料恢復】EMC Unity儲存誤刪除的資料恢復案例伺服器資料恢復Unity
- 【伺服器資料恢復】EMC Isilon儲存誤刪除的資料恢復案例伺服器資料恢復
- 【NetApp資料恢復】誤刪除NetApp上的lun導致伺服器當機的NetApp資料恢復APP資料恢復伺服器
- 誤刪除儲存SqlServer資料庫資料恢復SQLServer資料庫資料恢復
- 【oracle資料庫資料恢復】誤操作導致的資料庫誤刪除的資料恢復案例Oracle資料庫資料恢復
- 【伺服器資料恢復】伺服器誤刪除lun如何恢復資料?伺服器資料恢復
- 儲存刪除資料後恢復方法-適用netAPP儲存APP
- 【伺服器資料恢復】EMC伺服器Isilon儲存誤刪除的資料恢復案例伺服器資料恢復
- NetApp資料恢復—NetApp儲存池中劃分的卷丟失的資料恢復案例APP資料恢復
- 伺服器資料恢復—NTFS誤操作刪除/格式化的資料恢復案例伺服器資料恢復
- 伺服器資料恢復—EMC儲存資料卷被誤刪除如何恢復資料?伺服器資料恢復
- 【伺服器資料恢復】XenServer虛擬機器被誤操作刪除的資料恢復案例伺服器資料恢復Server虛擬機
- 【VSAN資料恢復】VSAN儲存資料恢復案例資料恢復
- 儲存崩潰資料恢復過程;資料恢復案例資料恢復
- EMC 儲存資料恢復案例詳解【資料恢復方案】資料恢復
- 【分散式儲存資料恢復】hbase和hive資料庫底層檔案誤刪的資料恢復案例分散式資料恢復Hive資料庫
- oracle恢復誤刪除資料Oracle
- 【北亞資料恢復】分散式儲存hbase和hive資料庫底層檔案被誤刪除的資料恢復案例資料恢復分散式Hive資料庫
- 【儲存資料恢復】EqualLogic PS系列儲存磁碟故障的資料恢復案例資料恢復
- 【伺服器儲存裝置資料恢復】EMC儲存裝置POOL上的資料卷被刪除的資料恢復案例伺服器資料恢復
- 【伺服器儲存資料恢復】HP-Lefthand儲存資料恢復案例伺服器資料恢復
- Sybase ASE資料庫恢復,Sybase資料恢復,資料誤刪除恢復工具READSYBDEVICE資料庫資料恢復dev
- 【虛擬化資料恢復】KVM虛擬機器誤刪除資料恢復案例資料恢復虛擬機
- 【伺服器資料恢復】HP EVA儲存資料恢復案例伺服器資料恢復
- 【北亞資料恢復】誤刪除oracle表和誤刪除oracle表資料的資料恢復方法資料恢復Oracle
- NetApp FAS2240-4儲存刪除檔案資料恢復APP資料恢復
- 【儲存資料恢復】esx vmfs的互斥導致儲存資料丟失的資料恢復案例資料恢復
- Vsan資料恢復—Vsan分散式儲存資料恢復案例資料恢復分散式
- 【伺服器資料恢復】infortrend ESDS系列儲存資料恢復案例伺服器資料恢復
- EMC UNITY 400儲存卷刪除資料恢復操作過程Unity資料恢復
- SQL Server資料庫恢復,SQL Server資料恢復,SQL Server資料誤刪除恢復工具SQLRescueSQLServer資料庫資料恢復