數據恢復有沒有簡易方案？

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

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

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

預先準備

工具

我們要用到以下工具

排查和診斷就是數據處理

如果對數據處理了解不多，請參考OSEMN

1. obtaining data/獲取數據

2. crubbing data/清洗數據

3. exploring data/探索數據

4. modeling data/建模數據

5. interpreting data/解釋數據

測試環境

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

數據恢復的原理和流程

什麼是元數據？

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

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

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

具體看看分區的數據結構。以fdisk為例，分區的數據結構定義為

struct dos_partition { unsigned char boot_ind; /* 0x80 - active */

我們看看具體分區的例子，驗證一下數據結構

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

類似分區信息這種系統用以管理某層資源的數據就是元數據。

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

下面是一份完整的LVM元數據信息，有興趣者可以逐一清點各個對象。

[root@pusf ~]# pvdisplay;vgdisplay;lvdisplay

元數據和數據：數據損壞分類

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

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

當然，如果數據損壞了，即使元數據完好無缺，那麼數據也是損壞了。比如，你誤刪了一個文件，那麼，分區結構再完好對於文件被刪也於事無補。

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

元數據修復可以簡易處理

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

原理

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

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

比如我們有一塊數據盤，整盤我們只是用fdisk分了一個區，現在分區丟失了。這種情形下，只要用fdsik，按照默認情形，重新分區就能恢復分區。

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

癥狀和初步排查

癥狀

客戶反饋

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

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

但是客戶的邏輯卷上有重要數據。此邏輯卷在數據盤上，數據盤大小是2TB。此磁碟全部2TB全部分配給一個分區，此分區上創建有LVM結構。

分區數據如下

[root@localhost ~]# fdisk -l -u /dev/vdbDisk /dev/vdb: 2199.0 GB, 2199023255552 bytes

初步排查

首先確定分區上是否有數據，通過查看一些扇區，我們就會有很大的概率確認這一點。當然也可以逐扇區確認。

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

max_sector_to_check=nrsectorfor i in $(seq 0 ${max_sector_to_check});do dd if=/dev/vdb bs=512 count=1 skip=${i} 2>/dev/null | sha256sum;done | sort -n | uniq;

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

[root@localhost ~]# dd if=/dev/vdb1 bs=512 count=60 2>/dev/null | od -tx10000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0007000 f9 80 00 00 f9 80 01 00 f9 80 02 00 f9 80 03 000007020 f9 80 04 00 f9 80 0c 00 f9 80 0d 00 f9 80 18 000007040 f9 80 28 00 f9 80 3e 00 f9 80 79 00 f9 80 ab 000007060 f9 80 38 01 f9 80 6c 01 f9 80 45 04 f9 80 b0 040007100 f9 80 1a 06 f9 80 d0 0c f9 80 84 1e 00 00 00 000007120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0017000 fa 80 00 00 fa 80 01 00 fa 80 02 00 fa 80 03 000017020 fa 80 04 00 fa 80 0c 00 fa 80 0d 00 fa 80 18 000017040 fa 80 28 00 fa 80 3e 00 fa 80 79 00 fa 80 ab 000017060 fa 80 38 01 fa 80 6c 01 fa 80 45 04 fa 80 b0 040017100 fa 80 1a 06 fa 80 d0 0c fa 80 84 1e 00 00 00 000017120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0027000 fb 80 00 00 fb 80 01 00 fb 80 02 00 fb 80 03 000027020 fb 80 04 00 fb 80 0c 00 fb 80 0d 00 fb 80 18 000027040 fb 80 28 00 fb 80 3e 00 fb 80 79 00 fb 80 ab 000027060 fb 80 38 01 fb 80 6c 01 fb 80 45 04 fb 80 b0 040027100 fb 80 1a 06 fb 80 d0 0c fb 80 84 1e 00 00 00 000027120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0037000 fc 80 00 00 fc 80 01 00 fc 80 02 00 fc 80 03 000037020 fc 80 04 00 fc 80 0c 00 fc 80 0d 00 fc 80 18 000037040 fc 80 28 00 fc 80 3e 00 fc 80 79 00 fc 80 ab 000037060 fc 80 38 01 fc 80 6c 01 fc 80 45 04 fc 80 b0 040037100 fc 80 1a 06 fc 80 d0 0c fc 80 84 1e 00 00 00 000037120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0047000 fd 80 00 00 fd 80 01 00 fd 80 02 00 fd 80 03 000047020 fd 80 04 00 fd 80 0c 00 fd 80 0d 00 fd 80 18 000047040 fd 80 28 00 fd 80 3e 00 fd 80 79 00 fd 80 ab 000047060 fd 80 38 01 fd 80 6c 01 fd 80 45 04 fd 80 b0 040047100 fd 80 1a 06 fd 80 d0 0c fd 80 84 1e 00 00 00 000047120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0057000 fe 80 00 00 fe 80 01 00 fe 80 02 00 fe 80 03 000057020 fe 80 04 00 fe 80 0c 00 fe 80 0d 00 fe 80 18 000057040 fe 80 28 00 fe 80 3e 00 fe 80 79 00 fe 80 ab 000057060 fe 80 38 01 fe 80 6c 01 fe 80 45 04 fe 80 b0 040057100 fe 80 1a 06 fe 80 d0 0c fe 80 84 1e 00 00 00 000057120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0067000 ff 80 00 00 ff 80 01 00 ff 80 02 00 ff 80 03 000067020 ff 80 04 00 ff 80 0c 00 ff 80 0d 00 ff 80 18 000067040 ff 80 28 00 ff 80 3e 00 ff 80 79 00 ff 80 ab 000067060 ff 80 38 01 ff 80 6c 01 ff 80 45 04 ff 80 b0 040067100 ff 80 1a 06 ff 80 d0 0c ff 80 84 1e 00 00 00 000067120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00*0074000[root@localhost ~]#

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

初次恢復嘗試

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

[root@localhost ~]# pvdisplay /dev/vdb

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

[root@localhost ~]# pvcreate --uuid "X1cHlO-kdFk-RZIM-1L12-qHit-0QA5-C1fZxm" --restorefile /etc/lvm/backup/vg_xxxxxx /dev/vdb1

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

問題出在哪裡？

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

dd if=/dev/vdb1 bs=512 count=128 2>/dev/null | od -tc

結果及其結果分析如下

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

strace -s 512 pvdisplay

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

starce -o path_to_strace_log -s 512 -f -ff pvdisplay

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

strace -o /tmp/pvdisplay-strace.log -s 512 pvdisplaygrep grep -E "^open|^lseek|^read" /tmp/pvdisplay-strace.log

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

[root@localhost ~]# grep -E "^open|^lseek|^read|^close" /tmp/pvdisplay-strace.log

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

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

數據恢復

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

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

結語

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！