劣化した5回目の襲撃からの極端なデータ回復

実際のイベントに書かれています。

アクションを繰り返したり、急いで判断したりすると、データが完全に失われる可能性があります。 HowTo-shnikovではなく、この資料は、ディスクメディア上のデータのプレゼンテーションの図を再現するためのものです。



それでは始めましょう。 入力データ：

• 7つのディスク、それぞれに2つのプライマリパーティション。
• 最初のパーティション7および複数のミラーリング（RAID1）。
• RAID5の2番目のパーティション。その下でLVMが回転しています。

電気の急増と鉄に関するその他の問題により、2つのディスクが一晩で故障します。 ディスクを組み立て直す試みは、次のように失敗しました。 システムは、すべてのことに加えて、死亡した襲撃のオートパイロットで2時間動作しました。ディスクは生き返ったか、再び死亡しました。カーネルは、現時点でどのディスクをどの場所で動作させなかったか、つまり 彼らに書かれたものとそれがどのように起こったのか-推測しかできません。

一般的に、完全に死んだレイドがあります。 ここではmdadmは無力です。



すでに行われたことは戻らず、何らかの形でデータを復元する必要があります。 なぜなら バックアップ、いつものように、いいえ。 行動計画：

1. 残っているデータを新しいディスクにコピーします。
2. 元のディスクの順序を復元します。
3. 殺されたディスクを隔離するには（ポイント1を参照）。
4. RAIDフォーマット（メタ）を計算します。ソフトレイドは何らかのバージョンから始まり、ディスクのヘッダーにこのデータを保存する前に、ディスクの先頭に1 kbを割り当てます。
5. チャンク/ストライプのサイズを計算します。64kから512kに変更されました。
6. ディスクを組み立てる
7. LVMを回復し、論理ボリュームを書き換えます

パラグラフ1によると。

すべてが簡単です。より大きなボリュームの新しいディスクを購入し、それらにLVMを作成し、ディスクごとに個別のLVを選択し、ddを使用して2番目のパーティションをコピーします。 データを十分に長く再生する必要があります。

次に、残りのアイテムについて説明します。

理論は次のとおりです。ディスクの順序とチャンクのサイズを決定するには、イベントの日付と時刻が記録される何らかのログファイルを見つける必要があります。 すぐに言ってやった。 私の場合、ログファイルは別のlvセクションにありました。 仕事には、十分なサイズのディレクトリも必要です（私の場合、仕事に200 GBを割り当てました）。 研究に着きます。 各ドライブから最初の64kを取得します。

for i in abcdefg; do dd if=/dev/jbod/sd${i} bs=64 count=1024 of=/mnt/recover/${i}; done







64 kbの7つのファイルを取得します。 ここで、どのmdメタデータ形式が使用されているかをすぐに理解できます。 たとえば、メタデータ1、1.0、1.1、1.2の場合、次のようになります。

mega@megabook ~ $ dd if=/dev/gentoo/a bs=1024 count=64 | hexdump -C

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

00001000 fc 4e 2b a9 01 00 00 00 00 00 00 00 00 00 00 00 |.N+.............|

00001010 ee 6f de dc c3 94 9c 58 47 d0 cc 91 9c f7 c5 35 |.o.....XG......5|

00001020 6d 65 67 61 62 6f 6f 6b 3a 30 00 00 00 00 00 00 |megabook:0......|

00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00001040 96 e2 6c 4e 00 00 00 00 05 00 00 00 02 00 00 00 |..lN............|

00001050 00 5c 00 00 00 00 00 00 00 04 00 00 07 00 00 00 |.\..............|

00001060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

00001080 00 04 00 00 00 00 00 00 00 5c 00 00 00 00 00 00 |.........\......|

00001090 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

000010a0 00 00 00 00 00 00 00 00 64 23 f5 c9 5f 2a 64 68 |........d#.._*dh|

000010b0 e8 92 f2 1a 8c ca ad 98 00 00 00 00 00 00 00 00 |................|

000010c0 9a e2 6c 4e 00 00 00 00 12 00 00 00 00 00 00 00 |..lN............|

000010d0 ff ff ff ff ff ff ff ff f6 51 38 f5 80 01 00 00 |.........Q8.....|

000010e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

00001100 00 00 01 00 02 00 03 00 04 00 05 00 fe ff 06 00 |................|

00001110 fe ff fe ff fe ff fe ff fe ff fe ff fe ff fe ff |................|

*

00001400 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

64+0

64+0

65536 (66 kB)00010000

, 0,000822058 c, 79,7 MB/c







mega@megabook ~ $ mdadm -D /dev/md0

/dev/md0:

Version : 1.2

Creation Time : Sun Sep 11 20:32:22 2011

Raid Level : raid5

Array Size : 70656 (69.01 MiB 72.35 MB)

Used Dev Size : 11776 (11.50 MiB 12.06 MB)

Raid Devices : 7

Total Devices : 7

Persistence : Superblock is persistent



Update Time : Sun Sep 11 20:32:26 2011

State : clean

Active Devices : 7

Working Devices : 7

Failed Devices : 0

Spare Devices : 0



Layout : left-symmetric

Chunk Size : 512K



Name : megabook:0 (local to host megabook)

UUID : ee6fdedc:c3949c58:47d0cc91:9cf7c535

Events : 18



Number Major Minor RaidDevice State

0 253 21 0 active sync /dev/dm-21

1 253 22 1 active sync /dev/dm-22

2 253 23 2 active sync /dev/dm-23

3 253 24 3 active sync /dev/dm-24

4 253 25 4 active sync /dev/dm-25

5 253 26 5 active sync /dev/dm-26

7 253 27 6 active sync /dev/dm-27







これはメタデータ1.2の例です。 特徴的な機能は、ブロックがほぼ同じコンテンツ（ディスク番号を除く）であり、残りのスペースがNULLで埋められることです。 RAID情報は次のアドレスにあります：0x00001000-0x00001ffff。

メタデータの以前のバージョンでは、RAID情報はディスクレイアウト領域に記録され、データはデバイスですぐに開始されました。 これは、メタデータ0.9では次のようになります。

~ # dd if=/dev/jbod/sdb bs=1024 count=1 | hexdump -C

1+0

1+0

1024 (1,0 kB), 0,0200084 c, 51,2 kB/c

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

00000200 4c 41 42 45 4c 4f 4e 45 01 00 00 00 00 00 00 00 |LABELONE........|

00000210 1b 72 36 1f 20 00 00 00 4c 56 4d 32 20 30 30 31 |.r6. ...LVM2 001|

00000220 66 6d 59 33 4a 35 6b 72 46 73 6d 52 51 41 47 66 |fmY3J5krFsmRQAGf|

00000230 4c 30 72 53 6b 69 59 6e 31 43 6c 72 66 61 66 70 |L0rSkiYn1Clrfafp|

00000240 00 00 fa ff ed 02 00 00 00 00 06 00 00 00 00 00 |................|

00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000260 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 |................|

00000270 00 f0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

00000400









ディスクから最初の64kbをさらに調べた後、奇妙な特徴が浮上しました。 結局のところ、LVMはLVマークアップ情報をクリアテキストで保存します。 次のようになります。

vg0 {

id = "xxxx"

seqno = 64

status = ["RESIZEABLE", "READ", "WRITE"]

extent_size = 8192 # 4 Megabytes

max_lv = 0

max_pv = 0



physical_volumes {



pv0 {

id = "xxxxx"

device = "/dev/md2" # Hint only



status = ["ALLOCATABLE"]

dev_size = 5848847616 # 2,72358 Terabytes

pe_start = 384

pe_count = 713970 # 2,72358 Terabytes

}

}



logical_volumes {

--//--

log {

id = "l8OVMc-BUAj-YrIT-w8mh-YkvH-riS3-p1h6OY"

status = ["READ", "WRITE", "VISIBLE"]

segment_count = 2



segment1 {

start_extent = 0

extent_count = 12800 # 50 Gigabytes



type = "striped"

stripe_count = 1 # linear



stripes = [

"pv0", 410817

]

}

segment2 {

start_extent = 12800

extent_count = 5120 # 20 Gigabytes



type = "striped"

stripe_count = 1 # linear



stripes = [

"pv0", 205456

]

}

}

--//--

}







いいね！ これから何が必要ですか。 導かれるべき主な数字は次のとおりです。

• extent_size = 8192＃4メガバイト
• pe_start = 384
• ストライプ= [pv0、410817]
• extent_count = 5120

これらの数字は何ですか...

• extent_sizeはクラスターサイズのようなものです。 VGスペース全体が分割される最小単位。 なぜ4メガバイトで、そのようなオウムが測定されるのですか？ 私はそれを見たときにこの質問もしましたが、判明したように、すべてが簡単です-クラスターサイズは512バイト* 8192 = 4 Mbです
• pe_start -LVM ヘッダーはどこで終わり 、データはどこで始まります。
• extent_count-セクションに割り当てられたブロックの数。
• stripes = [pv0、xxxx] -どこからどのPVにセクションが配置されているか。

7台のドライブで5回目のレイドを行い、すべての数値を6で割ることを忘れないでください（7回目はパリティなので）。

少なくとも何らかのログを見つけてください。 見るべき手/目-ユートピア、台本を書く：

dd if=/dev/recover/sda bs=512 skip=$[(8192*410817+384)/6] | hexdump -C | grep 'Aug 28' | head







ここで：

skip=(extent_size*stripes+pe_start)/6

bs=512 --







ディスクを少しざわめかせた後、出力に次のようなものが表示されます。

02d08100 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 36 20 |Aug 28 00:06:06 |

02d081c0 3d 0a 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 |=.Aug 28 00:06:0|

02d08410 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 37 20 |Aug 28 00:06:07 |

02d08570 70 0a 41 75 67 20 32 38 20 30 30 3a 30 36 3a 30 |p.Aug 28 00:06:0|

02d085d0 65 78 74 3d 0a 41 75 67 20 32 38 20 30 30 3a 30 |ext=.Aug 28 00:0|

02d086b0 64 3d 2a 29 29 22 0a 41 75 67 20 32 38 20 30 30 |d=*))".Aug 28 00|

02d08710 65 73 74 61 6d 70 0a 41 75 67 20 32 38 20 30 30 |estamp.Aug 28 00|

02d08770 73 3d 30 20 74 65 78 74 3d 0a 41 75 67 20 32 38 |s=0 text=.Aug 28|

02d089c0 6f 72 64 3d 2a 29 29 22 0a 41 75 67 20 32 38 20 |ord=*))".Aug 28 |

02d08a20 6d 65 73 74 61 6d 70 0a 41 75 67 20 32 38 20 30 |mestamp.Aug 28 0|







アドレス02d08770を取得し、残りを512で除算すると、次のようになります。

mega@megabook ~ $ echo $[0x02d08770/512]

92227

mega@megabook ~ $ echo $[0x02d08770/512/2048]

45







数メガバイトを入れて、そこで何が起こるか見てみましょう：

for i in abcdefg; do dd if=/dev/recover/sd${i} of=/mnt/recover/${i} bs=512 count=1024 skip=$[(8192*410817+384)/6+(48*2048)] ; done







512kbの7ファイルを取得します。 テキストエディタで開き、チェックサム（パリティ）から読み取られるファイルの日付を確認します。 ディスクの順序を調整し、チャンクのサイズを確認します。 チェックサムが64 kbの後に開始する場合、64 kb、そうでない場合は、おそらく512以上です。 1ブロックのオフセットでアクションを繰り返します。

for i in abcdefg; do dd if=/dev/recover/sd${i} of=/mnt/recover/${i}.1 bs=512 count=1024 skip=$[(8192*410817+384)/6+(48*2048)+1] ; done







紙の上にテーブルを作ります。 どのドライブが最初で、どこがパリティブロックです。 5つのRAIDには、左非同期、左同期、右非同期、右同期の4つの順序があると言っても間違いありません。 詳細については、 www.accs.com / p_and_p / RAID / LinuxRAID.htmlをご覧ください。



打たれたディスクの拒否に関しては、創造的なタスクと上記の資料で十分です。



これで、チャンクのサイズ、メタデータテーブルのタイプ、およびセクションの順序がわかったので、mdadmで遊んでRAIDを再作成できます。 戦略的なトリックは、実際のディスクの代わりにmissingという単語を書き込むと、mdadmが劣化したraidを作成できることです。 知識を使用して、襲撃を作成しようとしています。 メタデータのタイプを必ず指定してください！ また、上記の資料を徹底的に研究することなく、次のコマンドを繰り返さないでください。 。 アレイの正しいアセンブリを確認するために、2 GBの仮想マシンパーティションを使用しました。

lvcreate -L2G -nnagios recover

mdadm -C /dev/md0 -l 5 -n 7 --metadata 0.9 -c 64 /dev/recover/[af] missing

dd if=/dev/md0 bs=512 skip=$[8192*XXXX+384] count=$[8192*512] | dd of=/dev/recover/nagios

cfdisk /dev/recover/nagios







cfdiskがディスクレイアウトテーブルが正しくないと言う場合、アレイを破棄し、ディスクの変位を使用してアレイの作成を繰り返します...最初のディスクは最後までスローされます。 つまり

mdadm -S /dev/md0

mdadm -C /dev/md0 -l 5 -n 7 --metadata 0.9 -c 64 /dev/recover/[bf] missing /dev/recover/a







セクションをコピーし、内容を見て、目的のシーケンスが見つかるまで繰り返します。 もちろん、電卓と一緒に座って、ログセクションを表示するときに計算したデータと住所に基づいて正確な順序を計算できます。

7番目のsdgディスクの代わりに、行方不明を書きました。ディスクの順序はagではなく、前のステップで取得したものである必要があります。 紛失すると、RAIDブロックがパリティブロックの再計算を拒否することになります。 自身が劣化していると見なし、緊急モードで動作します。



最初に持っているセクションを見つけたら、nagiosをコピーしたように、小さなLVセクションを選択して、イメージと肖像にコピーします。 マウントしてみてください。 間違ったドライブを投げた（紛失した）場合、dmesgはドライブのログに問題があることを報告する可能性があります（ドライブの1つがデータ曲線の形で寄与しているため）。 ブレークポイントを繰り返し、不足している位置を置き換えてディスクを作成およびコピーします。 つまり たとえば、行方不明の代わりに持っていたsdgドライブを追加し、sdfドライブの代わりに行方不明を書きます：

mdadm -C /dev/md0 -l 5 -n 7 --metadata 0.9 -c 64 /dev/recover/[be] missing /dev/recover/sdg /dev/recover/a







そして、取得されたデータが可能な限り関連するまで続きます。

シムでは、話は終わったと思います。

LVMの回復についていくつか説明します（これらのアドレスに悩まされないようにするため）。

ここではすべてが簡単です。 関連性を達成する場合-それ自体をアクティブにすることができます、そうでない場合は、通常、/ etc / lvm / backup / VG-NAMEでバックアップを取得します。 ルートパーティションが同じLVM上にあるため、このディレクトリを/ boot / lvmに移動し、シンボリックリンクを作成しました。 そして、すべてが簡単です：

vgcfgrestore -f /path/to/backup-file vg-name







これが助けにならなかった場合、たとえば、チェックサムで誓うようになった場合、このことを少しハッキングできます：

dd if=/dev/zero of=/dev/md0 bs=512 count=10

pvcreate /dev/md0

pvdisplay /dev/md0 | grep 'PV UUID'







次に、バックアップファイルを編集し、そこでUUIDを変更し、このセクションの前の部分と同じ名前でVGを作成します

vgcreate vg0 /dev/md0

vgcfgrestore -f /path/to/backup-file vg0







これらの不正行為の後、すべてを復元する必要があり、VGはバックアップファイルの作成時に関連します。



一般的に、シムでは、資料が十分に述べられていると思いますが、これらはすべて極端な手段であり、少なくともディスクの完全なコピー、つまり 作業はソースディスクではなく、キャストで行われます。

こちらもご覧ください：

• www.accs.com/p_and_p/RAID/LinuxRAID.html
• www.chiark.greenend.org.uk/~peterb/linux/raidextract
• code.google.com/p/pyraid/wiki/HOWTO
• www.chiark.greenend.org.uk/~peterb/linux/raidextract/stripesize#lvm1
• まあ、著者について忘れないでください