わかりました、他の人に同じ苦痛を与えるのを避けるために、私は自分の質問に答えます。
0. 警告
リカバリを行う場合は、常にデータをコピーして、そのコピーで作業してください。元の「壊れた」データを変更しないでください。そうは言っても、読み続けてください。
1.パーティションは次のようになります...
調査キットとテストディスクをインストールします。うまくいけば、あなたのディストリビューション用のパッケージがあるでしょう:)
# mmls -t gpt LUN01
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Safety Table
01: ----- 0000000000 0000000033 0000000034 Unallocated
02: Meta 0000000001 0000000001 0000000001 GPT Header
03: Meta 0000000002 0000000033 0000000032 Partition Table
04: 00 0000000034 0000002081 0000002048 LDM metadata partition
05: 01 0000002082 0000262177 0000260096 Microsoft reserved partition
06: 02 0000262178 1048576966 1048314789 LDM data partition
07: ----- 1048576967 1048576999 0000000033 Unallocated
注: testdisk は同じ情報を提供しますが、詳細は少なくなります # testdisk /list LUN01
2. ディスクのメタデータを抽出する
ディスクの順序、データ サイズ、およびパーティションに関するその他の暗号化された属性に関するすべての情報は、LDM メタデータ パーティションにあります。W2k8 は、このドキュメント [2] 以来、あまり変更されていませんが、一部のサイズは異なり、一部の属性は新しいものです (明らかに不明です)...
# dd if=LUN01 skip=33 count=2048 |xxd -a > lun01.metadata
# less lun01.metadata
行 0002410 に、サーバーの名前が表示されます。心強い?ただし、ディスクの順序とディスク ID を確認します。下へスクロール。
2.1. ディスクの順序
行 0003210 で、'Disk1' の後に長い文字列が続くはずです。
0003200: 5642 4c4b 0000 001c 0000 0006 0000 0001 VBLK............
0003210: 0000 0034 0000 003a 0102 0544 6973 6b31 ...4...:...Disk1
0003220: 2437 3965 3830 3239 332d 3665 6231 2d31 $79e80293-6eb1-1
0003230: 3164 662d 3838 6463 2d30 3032 3662 3938 1df-88dc-0026b98
0003240: 3335 6462 3300 0000 0040 0000 0000 0000 35db3....@......
0003250: 0048 0000 0000 0000 0000 0000 0000 0000 .H..............
これは、このボリュームの最初のディスクが次の一意の ID (UID) によって識別されることを意味します: 79e80293-6eb1-11df-88dc-0026b9835db3 しかし、現時点では、どのディスクにこの UID があるかわかりません! したがって、Disk2 エントリに移動し、ボリューム内にあったすべてのディスクの UID などをメモします。注: 私の経験に基づくと、最初の 8 文字のみが変更され、残りは同じままです。実際、W2k8 は ID を 6 ずつ増やしているようです。$ は区切り文字です。
例えば。:
Windows Disk1 UID : 79e80293-6eb1-11df-88dc-0026b9835db3
Windows Disk2 UID : 79e80299-...
Windows Disk3 UID : 79e8029f-...
2.2. ディスク UID を探す
行 00e8200 (lun01.metadata) に移動します。「PRIVHEAD」が見つかるはずです。
00e8200: 5052 4956 4845 4144 0000 2c41 0002 000c PRIVHEAD..,A....
00e8210: 01cc 6d37 2a3f c84e 0000 0000 0000 0007 ..m7*?.N........
00e8220: 0000 0000 0000 07ff 0000 0000 0000 0740 ...............@
00e8230: 3739 6538 3032 3939 2d36 6562 312d 3131 79e80299-6eb1-11
00e8240: 6466 2d38 3864 632d 3030 3236 6239 3833 df-88dc-0026b983
00e8250: 3564 6233 0000 0000 0000 0000 0000 0000 5db3............
00e8260: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00e8270: 3162 3737 6461 3230 2d63 3731 372d 3131 1b77da20-c717-11
00e8280: 6430 2d61 3562 652d 3030 6130 6339 3164 d0-a5be-00a0c91d
00e8290: 6237 3363 0000 0000 0000 0000 0000 0000 b73c............
00e82a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00e82b0: 3839 3164 3065 3866 2d64 3932 392d 3131 891d0e8f-d929-11
00e82c0: 6530 2d61 3861 372d 3030 3236 6239 3833 e0-a8a7-0026b983
00e82d0: 3564 6235 0000 0000 0000 0000 0000 0000 5db5............
00e82e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
求めているのは、この特定のディスクのディスク UID です。- ディスク ID: 79e80299-6eb1-11df-88dc-0026b9835db3 - ホスト ID: 1b77da20-c717-11d0-a5be-00a0c91db73c - ディスク グループ ID: 891d0e8f-d929-11e0-a8a7-0026b9835db5
したがって、UID 79e80299-... を持つこのディスクは Windows Disk2 ですが、私たちにとっては物理ディスク 1 でした。実際、この UID は上で見つけたディスクの順序で見つけてください。注: 論理的な順序はありません。つまり、Windows がディスクの順序を設定する方法を決定します。あなたではありません。したがって、人間の論理はなく、最初のディスクが Disk1 であるとは思わないでください。
したがって、上記の順序が人間の論理に従うと想定しないでください。ディスクのすべての LDM データを調べて、それらの UID を抽出することをお勧めします。(次のコマンドを使用して、PRIVHEAD 情報を抽出することができます: dd if=LUNXX skip=1890 count=1 |xxd -a)
例えば:
(Windows) Disk1 : 79e80293-... == Physical disk 2
(Windows) Disk2 : 79e80299-... == Physical disk 1
(Windows) Disk3 : 79e8029f-... == Physical disk 3
LDM メタデータのどこかにボリュームのタイプ (スパン、RAID0、RAIDX、および関連するストライプ サイズ) があるはずですが、まだ掘り下げていません。私は自分のデータを見つけるために「試行と再試行」の方法を使用しました。したがって、ドラマの前に構成をセットアップする方法を知っていれば、多くの時間を節約できます。
3. NTFS ファイルシステムとデータを見つける
ここで、復元したいデータの大部分に関心があります。私の場合は 512GB までのデータなので、全体を ASCII に変換しません。Windows が NTFS パーティションの先頭をどのように検出するかについては、あまり調べていません。しかし、私が見つけたのは、論理的に次のキーワードで始まることです: R.NTFS. これを見つけて、NTFS FS を確認するために後で適用する必要があるオフセットを見つけましょう。
06: 02 0000262178 1048576966 1048314789 LDM data partition
この例では、データは 262178 から始まり、1048314789 セクターの長さです。
上記で、(ボリューム グループの)Disk1 が実際には 2 番目の物理ディスクであることがわかりました。その情報の一部を抽出して、NTFS パーティションの開始位置を見つけます。
# dd if=LUN02 skip=262178 count=4096 |xxd -a > lun02.DATASTART-4k
# less lun02.DATASTART-4k
0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
00fbc00: eb52 904e 5446 5320 2020 2000 0208 0000 .R.NTFS .....
00fbc10: 0000 0000 00f8 0000 3f00 ff00 0008 0400 ........?.......
00fbc20: 0000 0000 8000 8000 ffaf d770 0200 0000 ...........p....
ここで、NTFS が 00fbc00 から始まることがわかります。これで、セクター 262178 + 00fbc00 バイトからデータを抽出できることがわかりました。16 進数から 10 進数への変換と、バイトからセクターへの変換も行ってみましょう。
0xfbc00 バイト = 1031168 バイト = 1031168/512 セクター = 2014 セクター
したがって、NTFS パーティションは 262178 + 2014 = 264192 セクターから始まります。この値は、後ですべてのディスクで使用するオフセットになります。これを NTFS オフセットと呼びましょう。明らかに、合計サイズはオフセットによって縮小されます。したがって、新しいサイズは次のとおりです。1048314789 - 2014 = 1048312775 セクター
4. データのマウント/表示を試みる
これからは、NTFS パーティションが正常であるためそのままで動作するか、一部のデータを回復するためにこれを行っているために動作しません。以下のプロセスは、あなたのステータスが何であれ同じです。以下はすべて [1] に基づいています (下部のリンクを参照してください)。
スパン ボリュームは、次々とボリュームを埋めます。ストライプ化された (RAID0) は、多くのディスクにデータのチャンクをコピーします (つまり、ファイルは多くのディスクに分散されます)。私の場合、それがスパン ボリュームなのかストライプ ボリュームなのかわかりませんでした。ボリュームがいっぱいになっていないかどうかを知る最も簡単な方法は、すべてのボリュームの最後に多数のゼロがあるかどうかを確認することです。その場合はストライプです。スパンされている場合、最初のディスクがいっぱいになり、次に2番目のディスクがいっぱいになるためです。私はそれを100%確信しているわけではありませんが、それは私が観察したことです. そのため、LDM データ パーティションの末尾から一連のセクターを追加します。
4.0 データにアクセスするための準備
最初に、上記で計算した NTFS オフセットとサイズを使用して、ループバック デバイスを介して dd ファイルまたはデバイスをマウントします。ただし、オフセットとサイズは、losetup で使用するセクターではなく、バイト単位である必要があります。オフセット = 264192*512 = 135266304 サイズ = 1048312775*512 = 536736140800
# losetup /dev/loop2 DDFILE_OR_DEVICE -o 135266304 --size 536736140800
# blockdev --getsize /dev/loop2
1048312775 <---- total size in sectors, same number than before
注: 「-r」を追加すると、読み取り専用モードでマウントできます。
ボリュームのすべての物理ディスク部分に対して上記を実行します。結果を表示するには: losetup -a 注: 十分な数のループ デバイスがない場合は、次のようにして簡単に作成できます: # mknod -m0660 /dev/loopNUMBER b 7 NUMBER && chown root.disk /dev/loopNUMBER
グループの最初のディスク (例: Disk2) を開いて配置を確認し、最初の行が R.NTFS であるかどうかを確認します。そうでない場合は、配置が間違っています。上記の計算を確認して、もう一度やり直してください。または、最初の Windows ディスクを見ていません。
例えば:
First disk of the volume has been mounted on /dev/loop2
# xxd /dev/loop2 |head
0000000: eb52 904e 5446 5320 2020 2000 0208 0000 .R.NTFS .....
0000010: 0000 0000 00f8 0000 3f00 ff00 0008 0400 ........?.......
すべて良い。迷惑な部分に移りましょう:)
4.1 スパンド
スパン ディスクは、実際にはディスクのチェーンです。最初のものを埋めてから、2番目のものを使用する、というように。次のようなファイルを作成します。
# Offset into Size of this Raid type Device Start sector
# volume device of device
0 1048312775 linear /dev/loop2 0
1048312775 1048312775 linear /dev/loop1 0
2096625550 1048312775 linear /dev/loop3 0
注: - 適切なディスク順序を使用することを忘れないでください (前に見つけました)。例: 物理ディスク 2 の後に物理ディスク 1 と物理ディスク 3 が続く - 2096625550 = 2*1048312775 で、明らかに 4 番目のディスクがある場合、4 番目のディスクのオフセットのサイズの 3 倍になります。
4.2 ストライプ
ストライプ モード (別名 RAID0) の問題は、ストライプ サイズを知る必要があることです。どうやらデフォルトでは64kです(私の場合は128kでしたが、Windowsシステム管理者によって調整されたかどうかはわかりません:)。とにかく、それがわからない場合は、可能なすべての標準値を試して、どれが実行可能な NTFS ファイルシステムを提供するかを確認する必要があります。
チャンク サイズが 128k の 3 つのディスクに対して、次のようなファイルを作成します。
.---+--> 3 chunks of 128k
0 3144938240 striped 3 128 /dev/loop2 0 /dev/loop3 0 /dev/loop1 0
`---> total size of the volume `----------+-----------+---> disk order
/!\ : ボリュームのサイズは、前に計算したサイズと正確には一致しません。dmsetup には、チャンク サイズ (別名ストライプ サイズ) とボリューム内のディスク数で割り切れるボリューム サイズが必要です。だから私たちの場合。1048312775 セクターのディスクが 3 つあるので、「通常の」サイズは 1048312775*3=3144938325 セクターですが、上記の制約により、サイズを再計算して丸めます # echo "3144938325/128*128" | 紀元前3144938240セクター
So 3144938240 is the size of your volume in a striped scenario with 3 disk and
128 chunks (aka stripes)
4.3 取り付けます。
dmsetup を使用してすべてを集約します。
# dmsetup create myldm /path/myconfigfile
# dmsetup ls
myldm (253, 1)
# mount -t ntfs -o ro /dev/mapper/myldm /mnt
マウントしない場合。次に、 testdisk を使用できます。
# testdisk /dev/mapper/myldm
--> Analyse
----> Quick search
------> You should see the volume name (if any). If not it seems compromised :)
--------> Press 'P' to see files and copy with 'c'
5。結論
上記は私のために働いた。あなたのマイレージは異なる場合があります。そして、それを行うためのより良い、より簡単な方法があるかもしれません。もしそうなら、それを共有して、他の誰もこの面倒を経験する必要がないようにしてください:)また、難しく見えるかもしれませんが、そうではありません. データをどこかにコピーしている限り、何かが見えるまで試してみてください。すべてのビットを組み合わせる方法を理解するのに 3 日かかりました。上記が 3 日間を無駄にしないために役立つことを願っています。
注: 上記の例はすべて作り話です。私の徹底にもかかわらず、例の間にいくつかの矛盾があるかもしれません;)
幸運を。
6. リンク