摘要：以黑箱方式完全依賴工具來進行數據恢復，所需時間和恢復的結果都難以估計。以專家或者專業方式進行數據恢復，技能和成本又太高。那么，數據恢復有沒有較為合適的簡易方案呢？我們以處理過的實際案例作答。
數據恢復有沒有簡易方案？
IT工程師一般都知道如何操作和使用文件和目錄。但是，對于系統如何構建出、抽象出文件和目錄，一般就不熟悉了。至于更下層的概念，可能大家知道最多的就是驅動了。所以，為了規避這點，可行的簡易方案之一，就是以黑箱方式使用testdisk等工具，在我們在對底層了解不多甚至一無所知的情況下，進行數據恢復（商業工具，恢復效果估計更好，當然商業工具的價格也更好）。但是，對于工程師而言，多數時候，僅僅以黑箱方式依賴某些工具進行數據恢復是不夠的。
數據恢復，經常是突發事故響應中關鍵而又耗時的一步。多數情況下，工程師往往并非專司數據恢復，操作環境往往是生產環境，趁手工具難以部署，執行操作要遵循種種約束，加之業務中斷的壓力。這種情形下，工程師很可能還需要推定數據恢復的結果/耗時等信息，提供數據供決策者使用。很明顯，如果你準備考驗一下自己的細致、耐心、知識和技能，數據恢復將是個不錯的課題。當然，有一點是明確的，只是以黑箱方式使用testdisk等工具進行數據恢復，解決以上問題是不可能的。那么，有沒有其他簡易方案呢？
這里，我們以一個實際的case為例，討論一下，在只使用UNIX常見工具（dd/grep/strace等）的情況下，如何簡單、快捷的恢復數據。
預先準備
工具
我們要用到以下工具
工具功能示例
bc計算器echo 'ibase=2^3;i=0107000;ibase=2^3+2;i/512' | bc -l
dd檢查或者拷貝磁盤/分區的內容，可以是幾個扇區，也可以是幾個字節dd if=/dev/sdb bs=1 count=64 skip=64 2>/dev/null | od -v -tx1
grep搜索制定字符串
od把二進制內容以ASCII或者16進制顯示出來，搭配dd使用可以代替二進制編輯器dd if=/dev/sdb bs=1 count=64 skip=64 2>/dev/null | od -v -tx1
strace追蹤應用的執行路徑和對數據處理的流程strace ps
排查和診斷就是數據處理
如果對數據處理了解不多，請參考OSEMN
obtaining data/獲取數據
crubbing data/清洗數據
exploring data/探索數據
modeling data/建模數據
interpreting data/解釋數據
測試環境
使用Virtualbox，基于CentOS/Fedora/debian/Ubuntu搭建Linux實驗環境。只需要學會strace工具和如下系統調用，就足以追蹤系統如何處理諸如LVM物理卷元數據這樣過的問題。
name功能
open打開一個文件，返回一個文件描述符供后續讀寫操作使用
dup/dup2復制文件描述符
lseek將讀寫指針移動到指定位置，后續操作從此指定位置讀寫
close關閉文件描述符
read讀操作
數據恢復的原理和流程
什么是元數據？
我們以大家都熟悉的磁盤作為存儲設備的例子。
現代操作系統都會在磁盤上建立多個分層結構來管理和控制磁盤。比如，磁盤分區，分區上建立物理卷，物理卷上建立卷組，卷組上建立邏輯卷，邏輯卷上建立文件系統，就是這樣的一個例子。如果你不熟悉LVM，請參考Logical Volume Manager。
這些分層的結構都是很類似的。以磁盤分區為例。所謂分區，以大家最為熟悉的MBR: Master Boot Record結構為例。其實是第一個扇區記錄了各個分區的起始扇區，大小和類型。系統需要時，比如啟動過程中，系統只要從磁盤的第一個扇區讀取這些數據即能拿到各個分區的數據。
具體看看分區的數據結構。以fdisk為例，分區的數據結構定義為
structdos_partition {unsignedcharboot_ind;/* 0x80 - active */unsignedcharbh, bs, bc;/* begin CHS */unsignedcharsys_ind;unsignedchareh, es, ec;/* end CHS */unsignedcharstart_sect[4];/* 分區開始扇區 */unsignedcharnr_sects[4];/* 分區包含的扇區數量 */} __attribute__((packed));
我們看看具體分區的例子，驗證一下數據結構
分區使得磁盤上的扇區有了差別。第一個扇區（其實其編號是0），因分區數據記錄其上而扮演特殊角色。明顯，對系統而言，管理和操作分區實際上就是讀寫第一扇區上的對應記錄而已。
類似分區信息這種系統用以管理某層資源的數據就是元數據。
系統在磁盤上建立的各個分層結構，都有類似分區結構的數據結構。以LVM結構為例，我們可以把磁盤記錄和LVM工具報告的數據做一對比。LVM數據的從第2個扇區開始，卷組數據在第8個扇區中，可以用dd命令提取相關扇區來驗證LVM的數據結構。
下面是一份完整的LVM元數據信息，有興趣者可以逐一清點各個對象。
[root@pusf ~]# pvdisplay;vgdisplay;lvdisplay--- Physical volume ---? PV Name? ? ? ? ? ? ? /dev/sda2? VG Name? ? ? ? ? ? ? cl? PV Size39.00GiB /notusable3.00MiB? AllocatableyesPE Size4.00MiB? Total PE9983Free PE1Allocated PE9982PV UUID? ? ? ? ? ? ? TIcs1T-Jksu-HKrn-fKqK-QF4K-ao1S-3PVBGI? --- Volume group ---? VG Name? ? ? ? ? ? ? cl? System ID? Format? ? ? ? ? ? ? ? lvm2? Metadata Areas1Metadata Sequence No5VG Access? ? ? ? ? ? read/write? VG Status? ? ? ? ? ? resizable? MAX LV0Cur LV2Open LV2Max PV0Cur PV1Act PV1VG Size39.00GiB? PE Size4.00MiB? Total PE9983Alloc PE / Size9982/38.99GiB? Free? PE / Size1/4.00MiB? VG UUID? ? ? ? ? ? ? KTVFwl-2QRE-ehf3-3dJb-bIfG-bpn0-8FnH7l? --- Logical volume ---? LV Path? ? ? ? ? ? ? ? /dev/cl/swap? LV Name? ? ? ? ? ? ? ? swap? VG Name? ? ? ? ? ? ? ? cl? LV UUID? ? ? ? ? ? ? ? Kc14dR-vFda-qdWJ-zUYo-lsDl-4oKq-RjjrBb? LV Write Access? ? ? ? read/write? LV Creation host, time localhost,2017-04-1813:23:08+0800LV Status? ? ? ? ? ? ? available# open? ? ? ? ? ? ? ? 2LV Size2.00GiB? Current LE512Segments1Allocation? ? ? ? ? ? inherit? Read ahead sectors? ? auto? - currently setto8192Block device253:1--- Logical volume ---? LV Path? ? ? ? ? ? ? ? /dev/cl/root? LV Name? ? ? ? ? ? ? ? root? VG Name? ? ? ? ? ? ? ? cl? LV UUID? ? ? ? ? ? ? ? PWaI2g-t2Kq-h3aa-HgMC-cBp1-FjBp-dmaGeR? LV Write Access? ? ? ? read/write? LV Creation host, time localhost,2017-04-1813:23:09+0800LV Status? ? ? ? ? ? ? available# open? ? ? ? ? ? ? ? 1LV Size36.99GiB? Current LE9470Segments1Allocation? ? ? ? ? ? inherit? Read ahead sectors? ? auto? - currently setto8192Block device253:0[root@pusf ~]# dd if=/dev/sda2 bs=512 count=16 skip=1 2>/dev/null | od -tc0000000L? A? B? E? L? O? N? E001\0\0\0\0\0\0\00000020270177251K\0\0\0L? V? M20010000040T? I? c? s1T? J? k? s? u? H? K? r? n? f? K0000060q? K? Q? F4K? a? o1S3P? V? B? G? I0000100\0\0360277\t\0\0\0\0\0020\0\0\0\0\00000120\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\00000140\0\0\0\0\0\0\0\0\0020\0\0\0\0\0\00000160\0360017\0\0\0\0\0\0\0\0\0\0\0\0\00000200\0\0\0\0\0\0\0\0002\0\0\0001\0\0\00000220\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0*0007000252314344w? ? ? L? V? M2x? [5A? %? r00070200N? *? >001\0\0\0\0020\0\0\0\0\0\00007040\0360017\0\0\0\0\0\0026\0\0\0\0\0\00007060027005\0\0\0\0\0\0026G205374\0\0\0\00007100\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0*0010000c? l? ? ? {\ni? d? ? ? ="? K? T? V? F? w
0010020? l? -? 2? Q? R? E? -? e? h? f? 3? -? 3? d? J? b
0010040? -? b? I? f? G? -? b? p? n? 0? -? 8? F? n? H? 7
0010060? l? "\ns? e? q? n? o? ? ? =1\nf? o? r0010100m? a? t? ? ? ="? l? v? m? 2? "\ns? t? a0010120t? u? s? ? ? =? ? ? ["? R? E? S? I? Z? E? A? B
0010140? L? E? ","? R? E? A? D? ","? W? R
0010160? I? T? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0010200\ne? x? t? e? n? t? _? s? i? z? e? ? ? =80010220192\nm? a? x? _? l? v? ? ? =0\nm0010240a? x? _? p? v? ? ? =0\nm? e? t? a? d? a0010260t? a? _? c? o? p? i? e? s? ? ? =0\n\np0010300h? y? s? i? c? a? l? _? v? o? l? u? m? e? s0010320{\n\np? v0{\ni? d? ? ? ="? T
0010340? I? c? s? 1? T? -? J? k? s? u? -? H? K? r? n? -
0010360? f? K? q? K? -? Q? F? 4? K? -? a? o? 1? S? -? 3
0010400? P? V? B? G? I? "\nd? e? v? i? c? e? ? ? =0010420"? /? d? e? v? /? s? d? a? 2? "\n\ns? t? a0010440t? u? s? ? ? =? ? ? ["? A? L? L? O? C? A? T? A
0010460? B? L? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0010500\nd? e? v? _? s? i? z? e? ? ? =817800105206880\np? e? _? s? t? a? r? t? ? ? =00105402048\np? e? _? c? o? u? n? t? ? ? =00105609983\n}\n}\n\n\n}\n#? ? ? G0010600e? n? e? r? a? t? e? d? ? ? b? y? ? ? L? V? M20010620v? e? r? s? i? o? n2.02.1600106406(2)? -? R? H? E? L7(20160010660-09-28)? :? ? ? T? u? e? ? ? A? p? r00107001805:23:0820100107207\n\nc? o? n? t? e? n? t? s? ? ? ="? T
0010740? e? x? t? ? ? F? o? r? m? a? t? ? ? V? o? l? u? m
0010760? e? ? ? G? r? o? u? p? "\nv? e? r? s? i? o? n0011000=1\n\nd? e? s? c? r? i? p? t? i? o0011020n? ? ? ="? "\n\nc? r? e? a? t? i? o? n0011040_? h? o? s? t? ? ? ="? l? o? c? a? l? h? o
0011060? s? t? "\t#? ? ? L? i? n? u? x? ? ? l? o? c? a0011100l? h? o? s? t3.10.0-5140011120.? e? l7.? x86_64#? 1? ? ? S0011140M? P? ? ? T? u? e? ? ? N? o? v22160011160:42:41U? T? C20160011200x86_64\nc? r? e? a? t? i? o? n? _0011220t? i? m? e? ? ? =14924929800112408\t#? ? ? T? u? e? ? ? A? p? r? ? ? 1? 8? ? ? 000112605:23:082017\n\n\0\00011300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0*0012000c? l? ? ? {\ni? d? ? ? ="? K? T? V? F? w
0012020? l? -? 2? Q? R? E? -? e? h? f? 3? -? 3? d? J? b
0012040? -? b? I? f? G? -? b? p? n? 0? -? 8? F? n? H? 7
0012060? l? "\ns? e? q? n? o? ? ? =2\nf? o? r0012100m? a? t? ? ? ="? l? v? m? 2? "\ns? t? a0012120t? u? s? ? ? =? ? ? ["? R? E? S? I? Z? E? A? B
0012140? L? E? ","? R? E? A? D? ","? W? R
0012160? I? T? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0012200\ne? x? t? e? n? t? _? s? i? z? e? ? ? =80012220192\nm? a? x? _? l? v? ? ? =0\nm0012240a? x? _? p? v? ? ? =0\nm? e? t? a? d? a0012260t? a? _? c? o? p? i? e? s? ? ? =0\n\np0012300h? y? s? i? c? a? l? _? v? o? l? u? m? e? s0012320{\n\np? v0{\ni? d? ? ? ="? T
0012340? I? c? s? 1? T? -? J? k? s? u? -? H? K? r? n? -
0012360? f? K? q? K? -? Q? F? 4? K? -? a? o? 1? S? -? 3
0012400? P? V? B? G? I? "\nd? e? v? i? c? e? ? ? =0012420"? /? d? e? v? /? s? d? a? 2? "\n\ns? t? a0012440t? u? s? ? ? =? ? ? ["? A? L? L? O? C? A? T? A
0012460? B? L? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0012500\nd? e? v? _? s? i? z? e? ? ? =817800125206880\np? e? _? s? t? a? r? t? ? ? =00125402048\np? e? _? c? o? u? n? t? ? ? =00125609983\n}\n}\n\nl? o? g? i? c? a0012600l? _? v? o? l? u? m? e? s? ? ? {\n\ns? w? a0012620p? ? ? {\ni? d? ? ? ="? K? c? 1? 4? d? R
0012640? -? v? F? d? a? -? q? d? W? J? -? z? U? Y? o? -
0012660? l? s? D? l? -? 4? o? K? q? -? R? j? j? r? B? b
0012700? "\ns? t? a? t? u? s? ? ? =? ? ? ["? R? E? A
0012720? D? ","? W? R? I? T? E? ","? V? I
0012740? S? I? B? L? E? "]\nf? l? a? g? s? ? ? =0012760[? ]\nc? r? e? a? t? i? o? n? _? t? i? m? e0013000=1492492988\nc? r0013020e? a? t? i? o? n? _? h? o? s? t? ? ? ="? l
0013040? o? c? a? l? h? o? s? t? "\ns? e? g? m? e? n0013060t? _? c? o? u? n? t? ? ? =1\n\ns? e? g0013100m? e? n? t1{\ns? t? a? r? t? _? e? x0013120t? e? n? t? ? ? =0\ne? x? t? e? n? t? _0013140c? o? u? n? t? ? ? =512\n\nt? y? p0013160e? ? ? ="? s? t? r? i? p? e? d? "\ns? t0013200r? i? p? e? _? c? o? u? n? t? ? ? =1\n\n0013220s? t? r? i? p? e? s? ? ? =? ? ? [\n"? p? v? 0
0013240? ",0\n]\n}\n}\n}\n\n}\n0013260#? ? ? G? e? n? e? r? a? t? e? d? ? ? b? y? ? ? L0013300V? M2v? e? r? s? i? o? n2.020013320.166(2)? -? R? H? E? L7(20013340016-09-28)? :? ? ? T? u? e0013360A? p? r1805:23:0800134002017\n\nc? o? n? t? e? n? t? s? ? ? =0013420"? T? e? x? t? ? ? F? o? r? m? a? t? ? ? V? o
0013440? l? u? m? e? ? ? G? r? o? u? p? "\nv? e? r? s0013460i? o? n? ? ? =1\n\nd? e? s? c? r? i? p0013500t? i? o? n? ? ? ="? "\n\nc? r? e? a? t0013520i? o? n? _? h? o? s? t? ? ? ="? l? o? c? a
0013540? l? h? o? s? t? "\t#? ? ? L? i? n? u? x? ? ? l0013560o? c? a? l? h? o? s? t3.10.0-0013600514.? e? l7.? x86_64#00136201S? M? P? ? ? T? u? e? ? ? N? o? v22001364016:42:41U? T? C20001366016x86_64\nc? r? e? a? t? i0013700o? n? _? t? i? m? e? ? ? =14924900137202988\t#? ? ? T? u? e? ? ? A? p? r? ? ? 10013740805:23:082017\n0013760\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\00014000c? l? ? ? {\ni? d? ? ? ="? K? T? V? F? w
0014020? l? -? 2? Q? R? E? -? e? h? f? 3? -? 3? d? J? b
0014040? -? b? I? f? G? -? b? p? n? 0? -? 8? F? n? H? 7
0014060? l? "\ns? e? q? n? o? ? ? =3\nf? o? r0014100m? a? t? ? ? ="? l? v? m? 2? "\ns? t? a0014120t? u? s? ? ? =? ? ? ["? R? E? S? I? Z? E? A? B
0014140? L? E? ","? R? E? A? D? ","? W? R
0014160? I? T? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0014200\ne? x? t? e? n? t? _? s? i? z? e? ? ? =80014220192\nm? a? x? _? l? v? ? ? =0\nm0014240a? x? _? p? v? ? ? =0\nm? e? t? a? d? a0014260t? a? _? c? o? p? i? e? s? ? ? =0\n\np0014300h? y? s? i? c? a? l? _? v? o? l? u? m? e? s0014320{\n\np? v0{\ni? d? ? ? ="? T
0014340? I? c? s? 1? T? -? J? k? s? u? -? H? K? r? n? -
0014360? f? K? q? K? -? Q? F? 4? K? -? a? o? 1? S? -? 3
0014400? P? V? B? G? I? "\nd? e? v? i? c? e? ? ? =0014420"? /? d? e? v? /? s? d? a? 2? "\n\ns? t? a0014440t? u? s? ? ? =? ? ? ["? A? L? L? O? C? A? T? A
0014460? B? L? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0014500\nd? e? v? _? s? i? z? e? ? ? =817800145206880\np? e? _? s? t? a? r? t? ? ? =00145402048\np? e? _? c? o? u? n? t? ? ? =00145609983\n}\n}\n\nl? o? g? i? c? a0014600l? _? v? o? l? u? m? e? s? ? ? {\n\ns? w? a0014620p? ? ? {\ni? d? ? ? ="? K? c? 1? 4? d? R
0014640? -? v? F? d? a? -? q? d? W? J? -? z? U? Y? o? -
0014660? l? s? D? l? -? 4? o? K? q? -? R? j? j? r? B? b
0014700? "\ns? t? a? t? u? s? ? ? =? ? ? ["? R? E? A
0014720? D? ","? W? R? I? T? E? ","? V? I
0014740? S? I? B? L? E? "]\nf? l? a? g? s? ? ? =0014760[? ]\nc? r? e? a? t? i? o? n? _? t? i? m? e0015000=1492492988\nc? r0015020e? a? t? i? o? n? _? h? o? s? t? ? ? ="? l
0015040? o? c? a? l? h? o? s? t? "\ns? e? g? m? e? n0015060t? _? c? o? u? n? t? ? ? =1\n\ns? e? g0015100m? e? n? t1{\ns? t? a? r? t? _? e? x0015120t? e? n? t? ? ? =0\ne? x? t? e? n? t? _0015140c? o? u? n? t? ? ? =512\n\nt? y? p0015160e? ? ? ="? s? t? r? i? p? e? d? "\ns? t0015200r? i? p? e? _? c? o? u? n? t? ? ? =1\n\n0015220s? t? r? i? p? e? s? ? ? =? ? ? [\n"? p? v? 0
0015240? ",0\n]\n}\n}\n\nr? o? o? t0015260{\ni? d? ? ? ="? P? W? a? I? 2? g? -
0015300? t? 2? K? q? -? h? 3? a? a? -? H? g? M? C? -? c
0015320? B? p? 1? -? F? j? B? p? -? d? m? a? G? e? R? "0015340\ns? t? a? t? u? s? ? ? =? ? ? ["? R? E? A? D
0015360? ","? W? R? I? T? E? ","? V? I? S
0015400? I? B? L? E? "]\nf? l? a? g? s? ? ? =? ? ? [0015420]\nc? r? e? a? t? i? o? n? _? t? i? m? e0015440=1492492989\nc? r? e0015460a? t? i? o? n? _? h? o? s? t? ? ? ="? l? o
0015500? c? a? l? h? o? s? t? "\ns? e? g? m? e? n? t0015520_? c? o? u? n? t? ? ? =1\n\ns? e? g? m0015540e? n? t1{\ns? t? a? r? t? _? e? x? t0015560e? n? t? ? ? =0\ne? x? t? e? n? t? _? c0015600o? u? n? t? ? ? =9470\n\nt? y? p0015620e? ? ? ="? s? t? r? i? p? e? d? "\ns? t0015640r? i? p? e? _? c? o? u? n? t? ? ? =1\n\n0015660s? t? r? i? p? e? s? ? ? =? ? ? [\n"? p? v? 0
0015700? ",512\n]\n}\n}\n}\n\n0015720}\n#? ? ? G? e? n? e? r? a? t? e? d? ? ? b? y0015740L? V? M2v? e? r? s? i? o? n2.001576002.166(2)? -? R? H? E? L70016000(2016-09-28)? :? ? ? T? u0016020e? ? ? A? p? r1805:23:0001604092017\n\nc? o? n? t? e? n? t? s0016060="? T? e? x? t? ? ? F? o? r? m? a? t
0016100? V? o? l? u? m? e? ? ? G? r? o? u? p? "\nv? e0016120r? s? i? o? n? ? ? =1\n\nd? e? s? c? r0016140i? p? t? i? o? n? ? ? ="? "\n\nc? r? e0016160a? t? i? o? n? _? h? o? s? t? ? ? ="? l? o
0016200? c? a? l? h? o? s? t? "\t#? ? ? L? i? n? u? x0016220l? o? c? a? l? h? o? s? t3.10.00162400-514.? e? l7.? x86_640016260#? 1? ? ? S? M? P? ? ? T? u? e? ? ? N? o? v00163002216:42:41U? T? C00163202016x86_64\nc? r? e? a0016340t? i? o? n? _? t? i? m? e? ? ? =14920016360492989\t#? ? ? T? u? e? ? ? A? p? r00164001805:23:0920100164207\n\n\0\0\0\0\0\0\0\0\0\0\0\0\00016440\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0*0017000c? l? ? ? {\ni? d? ? ? ="? K? T? V? F? w
0017020? l? -? 2? Q? R? E? -? e? h? f? 3? -? 3? d? J? b
0017040? -? b? I? f? G? -? b? p? n? 0? -? 8? F? n? H? 7
0017060? l? "\ns? e? q? n? o? ? ? =4\nf? o? r0017100m? a? t? ? ? ="? l? v? m? 2? "\ns? t? a0017120t? u? s? ? ? =? ? ? ["? R? E? S? I? Z? E? A? B
0017140? L? E? ","? R? E? A? D? ","? W? R
0017160? I? T? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0017200\ne? x? t? e? n? t? _? s? i? z? e? ? ? =80017220192\nm? a? x? _? l? v? ? ? =0\nm0017240a? x? _? p? v? ? ? =0\nm? e? t? a? d? a0017260t? a? _? c? o? p? i? e? s? ? ? =0\n\np0017300h? y? s? i? c? a? l? _? v? o? l? u? m? e? s0017320{\n\np? v0{\ni? d? ? ? ="? T
0017340? I? c? s? 1? T? -? J? k? s? u? -? H? K? r? n? -
0017360? f? K? q? K? -? Q? F? 4? K? -? a? o? 1? S? -? 3
0017400? P? V? B? G? I? "\nd? e? v? i? c? e? ? ? =0017420"? /? d? e? v? /? s? d? a? 2? "\n\ns? t? a0017440t? u? s? ? ? =? ? ? ["? A? L? L? O? C? A? T? A
0017460? B? L? E? "]\nf? l? a? g? s? ? ? =? ? ? [? ]0017500\nd? e? v? _? s? i? z? e? ? ? =817800175206880\np? e? _? s? t? a? r? t? ? ? =00175402048\np? e? _? c? o? u? n? t? ? ? =00175609983\n}\n\np? v1{\ni? d0017600="? R? c? p? o? 7? Z? -? Q? I? e? g? -
0017620? F? G? V? D? -? T? S? Z? I? -? s? o? Q? O? -? I
0017640? g? a? T? -? r? Q? w? D? 4? Y? "\nd? e? v? i0017660c? e? ? ? ="? /? d? e? v? /? s? d? b? 6? "0017700\n\ns? t? a? t? u? s? ? ? =? ? ? ["? A? L? L
0017720? O? C? A? T? A? B? L? E? "]\nf? l? a? g? s0017740=? ? ? [? ]\nd? e? v? _? s? i? z? e? ? ? =0017760409601\np? e? _? s? t? a? r? t0020000[root@pusf ~]#
元數據和數據：數據損壞分類
系統把磁盤的扇區分成兩種來支持分區：第一扇區和所有其他非第一扇區。并且在第一個扇區上記錄分區信息，即元數據。而其他非第一扇區則供分區層使用，從磁盤的視角看，其他非第一扇區則是數據部分。我們逐層考察下磁盤、分區和LVM結構
系統啟動時，會逐層讀取各層元數據，創建各層數據結構。如果某一層元數據損壞或者丟失，那么系統就沒有辦法完成創建各層數據結構的任務。這種情況下，從客戶角度看，很可能就是數據損壞了。比如，如果你把第一個扇區用\0覆蓋一遍，那么系統就識別不到分區內容了。當然這種情況下分區層以上的內容，比如物理卷信息，系統也無法處理了。因此，對于數據恢復任務而言，如果元數據損壞，則修復元數據總是必須的，而且往往是第一步。
當然，如果數據損壞了，即使元數據完好無缺，那么數據也是損壞了。比如，你誤刪了一個文件，那么，分區結構再完好對于文件被刪也于事無補。
基于以上分析，我們可以把數據損壞簡單分三類類：元數據損壞、數據損壞或者前面兩種損壞類型的混合型損壞。
元數據修復可以簡易處理
以基于磁盤的分區、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,2199023255552bytes5 heads,3sectors/track,286331153cylinders, total4294967296sectorsUnits = sectors of1*512=512bytesSector size (logical/physical):512bytes /512bytesI/O size (minimum/optimal):512bytes /512bytesDisk identifier: 0xde220917? Device Boot? ? ? Start? ? ? ? End? ? ? Blocks? Id? System/dev/vdb1204842949672942147482623+83Linux[root@localhost ~]#
初步排查
首先確定分區上是否有數據，通過查看一些扇區，我們就會有很大的概率確認這一點。當然也可以逐扇區確認。
逐扇區確認，可以用如下命令辦理。假設磁盤是/dev/vdb。
max_sector_to_check=nrsectorforiin$(seq0${max_sector_to_check});doddif=/dev/vdbbs=512count=1skip=${i}2>/dev/null| sha256sum;done |sort -n| uniq;
當然，也可以通過抽樣檢查來確認。這種方法通常是檢查磁盤分區的前面一部分扇區。比如，下面的例子，通過檢查前面幾十個扇區，我們可以確認磁盤上確有數據。
[root@localhost ~]# dd if=/dev/vdb1 bs=512count=602>/dev/null | od -tx1000000000000000000000000000000000000000*0007000f9800000f9800100f9800200f98003000007020f9800400f9800c00f9800d00f98018000007040f9802800f9803e00f9807900f980ab000007060f9803801f9806c01f9804504f980b0040007100f9801a06f980d00c f980841e00000000000712000000000000000000000000000000000*0017000fa800000fa800100fa800200fa8003000017020fa800400fa800c00fa800d00fa8018000017040fa802800fa803e00fa807900fa80ab000017060fa803801fa806c01fa804504fa80b0040017100fa801a06fa80d00c fa80841e00000000001712000000000000000000000000000000000*0027000fb800000fb800100fb800200fb8003000027020fb800400fb800c00fb800d00fb8018000027040fb802800fb803e00fb807900fb80ab000027060fb803801fb806c01fb804504fb80b0040027100fb801a06fb80d00c fb80841e00000000002712000000000000000000000000000000000*0037000fc800000fc800100fc800200fc8003000037020fc800400fc800c00fc800d00fc8018000037040fc802800fc803e00fc807900fc80ab000037060fc803801fc806c01fc804504fc80b0040037100fc801a06fc80d00c fc80841e00000000003712000000000000000000000000000000000*0047000fd800000fd800100fd800200fd8003000047020fd800400fd800c00fd800d00fd8018000047040fd802800fd803e00fd807900fd80ab000047060fd803801fd806c01fd804504fd80b0040047100fd801a06fd80d00c fd80841e00000000004712000000000000000000000000000000000*0057000fe800000fe800100fe800200fe8003000057020fe800400fe800c00fe800d00fe8018000057040fe802800fe803e00fe807900fe80ab000057060fe803801fe806c01fe804504fe80b0040057100fe801a06fe80d00c fe80841e00000000005712000000000000000000000000000000000*0067000ff800000ff800100ff800200ff8003000067020ff800400ff800c00ff800d00ff8018000067040ff802800ff803e00ff807900ff80ab000067060ff803801ff806c01ff804504ff80b0040067100ff801a06ff80d00c ff80841e00000000006712000000000000000000000000000000000*0074000[root@localhost ~]#
接下來使用testdisk工具恢復數據。嘗試數次，testdisk工具總是在掃描到2%時停滯，處理過程不能繼續。
初次恢復嘗試
分區還在，但是LVM結構丟失，經檢查，由LVM工具鏈維護的備份數據/etc/lvm/backup/vg_xxxxxx文件還在。因此，這種情形下，按照我們的恢復流程，只要在分區之上，嘗試重建LVM和文件系統，應該就可以解決問題。
[root@localhost~]# pvdisplay /dev/vdbFailedtofind deviceforphysical volume"/dev/vdb".[root@localhost~]# ls /etc/lvm/backup/vg_xxxxxx/etc/lvm/backup/vg_xxxxxx[root@localhost~]#
根據備份數據恢復LVM結構，可以參考Recovering Physical Volume Metadata。可惜的是，我們第一步就折戟沉沙了。
[root@localhost ~]# pvcreate --uuid "X1cHlO-kdFk-RZIM-1L12-qHit-0QA5-C1fZxm" --restorefile /etc/lvm/backup/vg_xxxxxx /dev/vdb1WARNING: Device /dev/vdb1 has sizeof4294965247sectors whichissmaller than corresponding PV sizeof4294966977sectors. Was device resized?? Oneormore devices usedasPVsinVG vg_xxxxxx have changed sizes.? Can't initialize physical volume"/dev/vdb1"ofvolume group"vg_xxxxxx"without-ff[root@localhost ~]#
看樣子，分區的數據有些地方出錯了。根據上面命令報錯的信息，對比LVM的備份數據和分區數據，很快我們就發現了問題。現有分區記錄的其擁有的扇區數目，少于其上LVM卷組記錄的扇區數量。
問題出在哪里？
因為種種原因，我們不能確認分區信息和LVM備份數據為何不一致。但是，我們可以進一步從磁盤上提取、分析數據。因為有關分區的元數據在（分區在），所以我們進一步檢查磁盤上還有沒有有關LVM的元數據？這只要使用下面的命令行
ddif=/dev/vdb1 bs=512count=1282>/dev/null| od -tc
結果及其結果分析如下
所以，磁盤上還有有關LVM的元數據，但是為什么系統沒有憑借這些數據構建出LVM結構呢？我們創建一個測試環境，用strace追蹤下系統處理LVM物理卷元數據的執行路徑。如下命令即可
strace-s512pvdisplay
當然，更好的辦法是把strace記錄放置到文件中，以備仔細檢查
starce -o path_to_strace_log-s512-f-ff pvdisplay
我們組合使用strace和grep命令來確認系統默認的LVM物理卷位置。如果你沒有耐心分析下面的數據，請跳過直接看后面的截圖
strace -o /tmp/pvdisplay-strace.log-s512pvdisplaygrep -E'^open|^lseek|^read'/tmp/pvdisplay-strace.log
數據清洗結果如下。如果沒有耐心分析，請跳過直接看下面的分析截圖
[root@localhost ~]# grep -E '^open|^lseek|^read|^close' /tmp/pvdisplay-strace.log…close(4)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? =0open("/dev/vdb1", O_RDONLY|O_DIRECT|O_NOATIME) =4close(4)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? =0open("/dev/vdb1", O_RDONLY|O_DIRECT|O_NOATIME) =4lseek(4,21037056, SEEK_SET)? ? ? ? ? ? =21037056read(4,"…",512) =512lseek(4,21118976, SEEK_SET)? ? ? ? ? ? =21118976read(4,"…",512) =512lseek(4,0, SEEK_SET)? ? ? ? ? ? ? ? ? =0read(4,"…",512) =512lseek(4,4096, SEEK_SET)? ? ? ? ? ? ? ? =4096read(4,"\26\326\216\333 LVM2 x[5A%r0N*>\1\0\0…",512) =512close(4)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? =0…[root@localhost ~]#
很明顯，系統預期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.數據恢復軟件列表
5.硬盤分區
6.RHEL 6 Logical Volume Manager Administration
9.元數據
本文為云棲社區原創內容，未經允許不得轉載，如需轉載請發送郵件至yqeditor@list.alibaba-inc.com；如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：yqgroup@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。
