目錄
一般 RAID Storage 只能對單 Block Device 做好冗餘、加速功能。但企業級儲存還需要儲存共用池（Storage Pool）、快照（Snapshot）、精簡空間（Thin Provisioning）、分層加速等。
能實現以上功能的，台廠的 Storage Server（含 NAS）多以開源架構為主，常見基於 mdadm、LVM、Btrfs、ext4、iSCSI LUN 等作法。
但當架構是封閉專用系統、且自行研發程式架構時，要怎樣做底層資料救援恢復？
以下是一個客戶求助於 IBM 原廠希望救回數據，最終沒辦法處理的狀況下，經由 IBM 與其他 SI 介紹一致建議送到 OSSLab 的實際案例。
機器不穩、硬碟嚴重損壞，Metadata 已經損壞
IBM Storwize V7000 隸屬於從 IBM DS8000 下放的儲存架構，可提供快照、精簡、分層功能，再分享成 SAN 與 iSCSI／FC。
這台在長久時間運作之下，硬碟已有壞軌，並且經過一些操作上 Metadata 已經損壞；整台儲存設備已經無法正常 Mount。
客戶先聯絡 IBM 原廠，考慮的恢復方式
對儲存進行強制上線操作，分析故障儲存中的故障硬碟離線順序 → 修復後離線的故障硬碟 → 將修復好的硬碟插回儲存設備，或是故意不修理，在 Drive Missing 狀態下進行強制上線操作。
這也是一般原廠技術能提供的恢復技術程度。本次案例 IBM 採用 Tier 3 Recovery（T5），流程如下：
- 清除兩個控制器數據 manager system — Remove system data
- 選 Recovery system — Prepare for recovery（如下圖）
IBM V7000 T5 Recovery 操作介面
- 等待跑完流程
但本次案例由原廠處理的 T5 恢復仍無法恢復資料，且 Metadata 可能已經被動到。
底層數據恢復：IBM 的 MDisk 架構分析
由於 IBM 原廠恢復層級僅到上述程度，因此本案只剩底層數據恢復選項可以做。
MDisk／Storage Pool／Volume（LUN）的關係
要做底層恢復，必須先完全搞懂 Storage 架構。IBM Storwize 的 MDisk 構成是由實體硬碟透過 RAID 0／1／5／6／10 模式所得來的。
MDisk 並不像一般 RAID 直接轉成 LUN，而是要考慮單個或多組 MDisk 組合：先歸類進哪組 Storage Pool，再決定採用 Mirror、Stripe、JBOD 哪種形式，最終依當初設定的 Pool 方式切分出不同 Volume（LUN）。
以下是 IBM Storwize 的 MDisk 架構簡述。
▲ IBM Storwize V7000 系列的 MDisk 架構。這個 Storage Pool 是由單 MDisk 所組成，而 Storage Pool 可以拿來建置映像模式的 Volume，以便透過 iSCSI 等協定給 Client 端存取。若 Volume 又是做 FAT LUN、無做精簡，是最簡單的救援狀況
▲ 這裡可以看到此 Storage Pool 由 3 顆 MDisk 所組成。當使用者從這個 Storage Pool 建立一個 Striped 的 Volume，那麼這個 Volume 真正存取到的 MDisk 磁碟排序，就會像右邊那樣的交錯方式。這種要做資料救援，就得再多重解析不同儲存層的 Pool 架構
▲ 若在 Storage Pool 建立一個 Sequential 的 Volume，那麼這個 Volume 真正存取到的 MDisk 磁碟排序，就會像右邊那樣的循序儲存式。這種要做資料救援，會比上面的 Striped Volume 簡單一點
為何有 MDisk？（擴充容量與冷熱資料分層）
為何需要 MDisk？主要是為了方便擴充容量與冷熱資料分層，可兼顧效能與備援擴充優勢。
例如：今天買了 10TB SAS 硬碟 4 顆，用 RAID 5 做成一個 MDisk 1（容量約 30TB），再將 MDisk 1 規劃成 Storage Pool，此時 Storage Pool 就有約 30TB 的可存取空間。
未來若容量不夠用，可以再新增硬碟：再擴充 16TB SAS 硬碟 5 顆，用 RAID 6 做成 MDisk 2（容量約 48TB），然後把 MDisk 2 注入 Storage Pool，則 Storage Pool 總容量約等於 30TB + 48TB = 78TB。此時可再切出多個 Volume 給既有或新裝好的 ESXi 伺服器使用，以達到零停機 Scale-up 的目標。
Storage Pool 最終分割出的 Volume（LUN），還會有前端 Bitmap、真實資料區、延伸資料區（快照過後的資料）。
IBM Storwize 的儲存層級（第 1～6 層）
從上面可以得知，IBM Storwize 的儲存層大致如下：
第一層：實體 SAS／FC／SATA 等硬碟
（真正裝在 Storwize 裡面的多顆硬碟）
若硬碟有硬體或韌體損壞，必須修復。OSSLab 實驗室有 PC3000 Portable SAS 救援裝置，可處理這類問題。
PC3000 Portable SAS 救援裝置
第二層：MDisk
（由實體 SAS or FC 硬碟以 RAID 0／5／6／10 建立而來）
- 做 MDisk 分析及重組：根據客戶給出的部分配置信息，將硬碟按照 MDisk 組分類。
- 分析每一組 MDisk 中的所有硬碟：得到相關 RAID 訊息、順序與 Stripe 大小。
- 使用專業數據恢復軟體：對 MDisk 進行軟 RAID 重組。
▲ 嘗試找出對應硬碟，並組合成 RAID（MDisk），最終再 dump 成映像檔
第三層：Pool 組態
Pool 組態可依照當初客戶設定資訊，來組合 MDisk 資料。不過若是 Stripe Pool 則必須分析出 Stripe Size 大小。如果是 Sequential 用 copy 指令也可以做的。
我們主要以 Python 腳本完成，參考 Python 腳本範例放在這。（非本次救援用腳本）
第四層：Volume／VDisk
如果為精簡（Thin Provisioning），前端還會有 Bitmap 延伸數據；必須先定位找出 Bitmap 與資料結構塊位置，找出算法。
第五層：LUN filesystem
以上組好的 LUN，為 VMFS。
客戶最需要資料，是 VMware vSphere 下其中一個 Linux Server 虛擬機裡面的 Oracle DB 檔案。必須使用到 Windows Mount VMFS 工具，以取出 DB 的 VMDK 檔案。
第六層：Data File
這次要取出的是 Ext4 檔案格式下的 Oracle DB 檔案。
驗證 Oracle DB 是很麻煩狀況，因為當下客戶的 AP 與 DB Server 都沒有送過來。OSSLab 這邊是以驗證 dbf（Oracle DataBase Format）資料庫檔案，來進行恢復成功度的評估。
搭配 Oracle 的 DBV（DBVerify）命令列工具做檔案內容一致性檢查；我們以這樣方式作驗收，普遍得到客戶技術部認同。
▲ 使用 DBV 工具查驗 dbf 資料庫檔案內容完整性
透過以上層層分析、拆解與救援，最終將客戶資料救回！
層層拆解分析，才是資料救援真核心技術
高難度數據恢復，必須如上所述全方面從底層開始，並必須具備：
- 有 SAS、SCSI、FC 硬碟維修設備與經驗
- 對 Infra、原廠處理手法與架構有經驗
- 能拆解底層檔案系統與算法
- 核對與驗證也必須科學、專業
這樣才是完整的數據恢復技術流程！
需要資料救援協助？
如果您的企業儲存設備發生故障，或有 RAID、NAS、SAN 資料復原需求，歡迎聯繫 OSSLAB 資料救援團隊進行評估。
圖片引用來源
以上部分圖片引用自 https://www.weithenn.org/2014/03/ibm-storwize.html
