Linux儲存入門：簡易資料恢復方案--分割槽和LVM實戰

摘要：

以黑箱方式完全依賴工具來進行資料恢復，所需時間和恢復的結果都難以估計。以專家或者專業方式進行資料恢復，技能和成本又太高。那麼，資料恢復有沒有較為合適的簡易方案呢？我們以處理過的實際案例作答。

資料恢復有沒有簡易方案？

IT工程師一般都知道如何操作和使用檔案和目錄。但是，對於系統如何構建出、抽象出文件和目錄，一般就不熟悉了。至於更下層的概念，可能大家知道最多的就是驅動了。所以，為了規避這點，可行的簡易方案之一，就是以黑箱方式使用testdisk等工具，在我們在對底層瞭解不多甚至一無所知的情況下，進行資料恢復（商業工具，恢復效果估計更好，當然商業工具的價格也更好）。但是，對於工程師而言，多數時候，僅僅以黑箱方式依賴某些工具進行資料恢復是不夠的。

資料恢復，經常是突發事故響應中關鍵而又耗時的一步。多數情況下，工程師往往並非專司資料恢復，操作環境往往是生產環境，趁手工具難以部署，執行操作要遵循種種約束，加之業務中斷的壓力。這種情形下，工程師很可能還需要推定資料恢復的結果/耗時等資訊，提供資料供決策者使用。很明顯，如果你準備考驗一下自己的細緻、耐心、知識和技能，資料恢復將是個不錯的課題。當然，有一點是明確的，只是以黑箱方式使用testdisk等工具進行資料恢復，解決以上問題是不可能的。那麼，有沒有其他簡易方案呢？

這裡，我們以一個實際的case為例，討論一下，在只使用UNIX常見工具（dd/grep/strace等）的情況下，如何簡單、快捷的恢復資料。

預先準備

工具

我們要用到以下工具

排查和診斷就是資料處理

如果對資料處理瞭解不多，請參考OSEMN

obtaining data/獲取資料

crubbing data/清洗資料

exploring data/探索資料

modeling data/建模資料

interpreting data/解釋資料

測試環境

使用Virtualbox，基於CentOS/Fedora/debian/Ubuntu搭建Linux實驗環境。只需要學會strace工具和如下系統呼叫，就足以追蹤系統如何處理諸如LVM物理卷元資料這樣過的問題。

資料恢復的原理和流程

什麼是元資料？

我們以大家都熟悉的磁碟作為儲存裝置的例子。

現代作業系統都會在磁碟上建立多個分層結構來管理和控制磁碟。比如，磁碟分割槽，分割槽上建立物理卷，物理捲上建立卷組，卷組上建立邏輯卷，邏輯捲上建立檔案系統，就是這樣的一個例子。如果你不熟悉LVM，請參考Logical Volume Manager。

這些分層的結構都是很類似的。以磁碟分割槽為例。所謂分割槽，以大家最為熟悉的MBR： Master Boot Record結構為例。其實是第一個扇區記錄了各個分割槽的起始扇區，大小和型別。系統需要時，比如啟動過程中，系統只要從磁碟的第一個扇區讀取這些資料即能拿到各個分割槽的資料。

具體看看分割槽的資料結構。以fdisk為例，分割槽的資料結構定義為

我們看看具體分割槽的例子，驗證一下資料結構

分割槽使得磁碟上的扇區有了差別。第一個扇區（其實其編號是0），因分割槽資料記錄其上而扮演特殊角色。明顯，對系統而言，管理和操作分割槽實際上就是讀寫第一扇區上的對應記錄而已。

類似分割槽資訊這種系統用以管理某層資源的資料就是元資料。

系統在磁碟上建立的各個分層結構，都有類似分割槽結構的資料結構。以LVM結構為例，我們可以把磁碟記錄和LVM工具報告的資料做一對比。LVM資料的從第2個扇區開始，卷組資料在第8個扇區中，可以用dd命令提取相關扇區來驗證LVM的資料結構。

下面是一份完整的LVM元資料資訊，有興趣者可以逐一清點各個物件。

元資料和資料：資料損壞分類

系統把磁碟的扇區分成兩種來支援分割槽：第一扇區和所有其他非第一扇區。並且在第一個扇區上記錄分割槽資訊，即元資料。而其他非第一扇區則供分割槽層使用，從磁碟的視角看，其他非第一扇區則是資料部分。我們逐層考察下磁碟、分割槽和LVM結構

系統啟動時，會逐層讀取各層元資料，建立各層資料結構。如果某一層元資料損壞或者丟失，那麼系統就沒有辦法完成建立各層資料結構的任務。這種情況下，從客戶角度看，很可能就是資料損壞了。比如，如果你把第一個扇區用\0覆蓋一遍，那麼系統就識別不到分割槽內容了。當然這種情況下分割槽層以上的內容，比如物理卷資訊，系統也無法處理了。因此，對於資料恢復任務而言，如果元資料損壞，則修復元資料總是必須的，而且往往是第一步。

當然，如果資料損壞了，即使元資料完好無缺，那麼資料也是損壞了。比如，你誤刪了一個檔案，那麼，分割槽結構再完好對於檔案被刪也於事無補。

基於以上分析，我們可以把資料損壞簡單分三類類：元資料損壞、資料損壞或者前面兩種損壞型別的混合型損壞。

元資料修復可以簡易處理

以基於磁碟的分割槽、LVM以及檔案系統為例。分層結構的資料格式都有嚴格的格式（比如分割槽的資料結構就是一個C的struct），出現位置也固定（有關分割槽的元資料記錄在第一個扇區的446～462位元組之間），而且這些資料結構往往都帶有魔數（比如，分割槽的型別83），而且常用的分層結構，也不外乎分割槽、LVM以及檔案系統等幾種。因此，對於元資料以及系統如何處理元資料，我們都容易追蹤和檢查。因此，可以預期，修復元資料，有簡易方案。

原理

如果有資料損壞，那麼除非有日誌、備份，或者資料本身有邏輯可供使用，否則資料是不能恢復了。比如，通常的檔案刪除操作，系統只是解除了檔名稱和檔案內容相關間的聯絡而已。檔案本身的內容還是記錄再磁碟上。這種情況下，只要重建檔名稱和檔案內容間的聯絡即可恢復檔案。

相對而言，簡單情形的是元資料損壞。如果只是元資料損壞，而且我們知道正確的元資料。因為元資料操作，不會觸及資料部分，因此，我們只要重建元資料部分即可恢復資料。如果涉及到多層，則逐層恢復即可。以分割槽丟失為例。

比如我們有一塊資料盤，整盤我們只是用fdisk分了一個區，現在分割槽丟失了。這種情形下，只要用fdsik，按照預設情形，重新分割槽就能恢復分割槽。

就這種情形，我們給出一個可用的分析流程。

症狀和初步排查

症狀

客戶反饋

降配重啟後，系統無法啟動

排查發現客戶一邏輯卷無法掛載導致重啟失敗。在/etc/fstab中註釋掉邏輯卷的掛載配置，系統啟動成功。

但是客戶的邏輯捲上有重要資料。此邏輯卷在資料盤上，資料盤大小是2TB。此磁碟全部2TB全部分配給一個分割槽，此分割槽上建立有LVM結構。

分割槽資料如下

初步排查

首先確定分割槽上是否有資料，透過檢視一些扇區，我們就會有很大的機率確認這一點。當然也可以逐扇區確認。

逐扇區確認，可以用如下命令辦理。假設磁碟是/dev/vdb。

當然，也可以透過抽樣檢查來確認。這種方法通常是檢查磁碟分割槽的前面一部分扇區。比如，下面的例子，透過檢查前面幾十個扇區，我們可以確認磁碟上確有資料。

接下來使用testdisk工具恢復資料。嘗試數次，testdisk工具總是在掃描到2%時停滯，處理過程不能繼續。

初次恢復嘗試

分割槽還在，但是LVM結構丟失，經檢查，由LVM工具鏈維護的備份資料/etc/lvm/backup/vg_xxxxxx檔案還在。因此，這種情形下，按照我們的恢復流程，只要在分割槽之上，嘗試重建LVM和檔案系統，應該就可以解決問題。

根據備份資料恢復LVM結構，可以參考Recovering Physical Volume Metadata。可惜的是，我們第一步就折戟沉沙了。

看樣子，分割槽的資料有些地方出錯了。根據上面命令報錯的資訊，對比LVM的備份資料和分割槽資料，很快我們就發現了問題。現有分割槽記錄的其擁有的扇區數目，少於其上LVM卷組記錄的扇區數量。

問題出在哪裡？

因為種種原因，我們不能確認分割槽資訊和LVM備份資料為何不一致。但是，我們可以進一步從磁碟上提取、分析資料。因為有關分割槽的元資料在（分割槽在），所以我們進一步檢查磁碟上還有沒有有關LVM的元資料？這隻要使用下面的命令列

結果及其結果分析如下

所以，磁碟上還有有關LVM的元資料，但是為什麼系統沒有憑藉這些資料構建出LVM結構呢？我們建立一個測試環境，用strace追蹤下系統處理LVM物理卷元資料的執行路徑。如下命令即可

當然，更好的辦法是把strace記錄放置到檔案中，以備仔細檢查

我們組合使用strace和grep命令來確認系統預設的LVM物理卷位置。如果你沒有耐心分析下面的資料，請跳過直接看後面的截圖

資料清洗結果如下。如果沒有耐心分析，請跳過直接看下面的分析截圖

很明顯，系統預期LVM元資料是在分割槽的第8個扇區，但是在需要做資料恢復的磁碟上，LVM的元資料卻是在第71個扇區，而分割槽的起始扇區是2048，因此，LVM資料根本不在分割槽內。這就是為什麼磁碟上還有LVM元資料，系統卻沒有識別出來LVM的原因。

既然系統是因為有關LVM的元資料所在扇區不對而導致系統無法識別LVM結構，設想透過重新分割槽，我們把有關LVM元資料調整到分割槽的第8個扇區。稍加計算，就會發現，只要把分割槽的起始扇區從第2048個扇區調整到第63個扇區即可。不僅如此，透過調整分割槽大小，我們同樣也解決了磁碟分割槽扇區數不足的問題

資料恢復

較新的fdisk工具，不允許起始扇區小於2048，因此，我們用parted工具來調整分割槽的起始扇區。

調整過程是先刪掉扇區，而後再建立之。而結果正如我們所預期的，分割槽調整完成，客戶的資料立刻恢復了。物理卷、卷組、邏輯卷、檔案系統以及資料，都完好無損。

結語

從處理這個實際case可以看出，如果知道如何識別各層元資料，比如分割槽，LVM和檔案系統；能夠追蹤系統處理各層元資料的邏輯，那麼，組合使用UNIX常用的dd、od等工具，足以簡單有效的處理元資料損壞的情形，快速恢復資料。如果掌握了常見的系統呼叫，並且掌握了strace工具，那麼對於如何識別元資料以及系統如何處理元資料，完全可以透過簡單分析strace輸出拿到相應答案。

除了易學、簡單、快捷、高效，元資料修復方案還有一個優點，就是可以確保不會破壞資料。這可能是這個方案的最大亮點。

參考

本文提供連結，優先連結內容的嚴謹與可靠性，而非便利性。如連結無法訪問，請按照文字自行檢索資料和圖書。

1。 資料恢復軟體列表

2。 shred （Unix）

3。 使用Linux檔案恢復工具

4。 如何恢復 Linux 上刪除的檔案，第 1 部分

5。 硬碟分割槽

6。 RHEL 6 Logical Volume Manager Administration

7。 Linux 檔案系統剖析

8。 Linux man pages online

9。 元資料

10。 Linux檔案系統中元資料的加鎖機制與組織方式