11

Linux で Windows 2008 LDM パーティションを読み取ることはできますか?

5 つの 512GB LUN が ISCSI を介して停止した Windows 2008 にエクスポートされましたが、このボックスはそれらを必要としなくなりました。Windows は、それらが未加工のデバイスであると認識しています...したがって、Linux でパーティションを読み取りたいと思います。最新の Ubuntu を使用して、少なくとも一部のデータを保存しようとしています。問題は、私がこれまでに見つけたすべてのドキュメントが時代遅れのように見えることです (w2k または XP 論理ディスク マネージャー (LDM) について話していることがよくあります)。しかし、2008 では違うと思います。

Testdisk [0] から次の出力が得られます

testdisk /list LUN01
TestDisk 6.11, Data Recovery Utility, April 2009
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Please wait...
Disk LUN01 - 536 GB / 500 GiB - CHS 65271 255 63, sector size=512

Disk LUN01 - 536 GB / 500 GiB - CHS 65271 255 63
     Partition                  Start        End    Size in sectors
 1 P MS LDM MetaData               34       2081       2048 [LDM metadata partition]
No FAT, NTFS, EXT2, JFS, Reiser, cramfs or XFS marker
 2 P MS Reserved                 2082     262177     260096 [Microsoft reserved partition]
 2 P MS Reserved                 2082     262177     260096 [Microsoft reserved partition]
 3 P MS LDM Data               262178 1048576966 1048314789 [LDM data partition]

注: 5 つの LUN のそれぞれに同じパーティション テーブルがあります。

cgssecuritykernel.orgなどの多くのドキュメントでは、有用な情報を返さない ldminfo について説明しています。見つけるのが非常に困難だったという理由だけで、現在は廃止されていると思います:)そして、機能しないため、Windows 2008は別の形式を使用していると思います。

# ldminfo LUN01
Something went wrong, skipping device 'LUN01'
# losetup /dev/loop1 LUN01
# losetup -a
/dev/loop1: [fd00]:14 (/mnt/LUN01)
# ldminfo /dev/loop1 
Something went wrong, skipping device '/dev/loop1'

次に、それらを dmsetup で連結しようとしましたが、やはりうまくいきませんでした。それが私が dmsetup を使用した方法です:

# losetup /dev/loop1 LUN01
# losetup /dev/loop2 LUN02
# losetup /dev/loop3 LUN03
# losetup /dev/loop4 LUN04
# losetup /dev/loop5 LUN05
# blockdev --getsize /dev/loop1
1048577000
# cat > w2008.mapping
# Offset into   Size of this    Raid type       Device          Start sector
# volume        device                                          of device
0               1048577000  linear          /dev/loop1       0
1048577000      1048577000  linear          /dev/loop2       0
2097154000      1048577000  linear          /dev/loop3       0
3145731000      1048577000  linear          /dev/loop4       0
4194308000      1048577000  linear          /dev/loop5       0
# dmsetup create myfs w2008.mapping
# mount -t ntfs /dev/mapper/myfs /mnt/final
NTFS signature is missing.
Failed to mount '/dev/loop1': Invalid argument
The device '/dev/loop1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
# echo Poo.

だからまだNTFSファイルシステムはありません:)

そこからデータを抽出する方法やポインタを教えてくれる方法について誰かアイデアがありますか?

4

3 に答える 3

10

わかりました、他の人に同じ苦痛を与えるのを避けるために、私は自分の質問に答えます。

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. リンク

于 2011-12-19T04:49:55.500 に答える
2

Windows ダイナミック ボリューム 5x ディスク、スパン、合計 8 TB。

これは、上記の回答から、[1] と [2] を参照して収集したものです。

私が発見したのは、メタデータ パーティションには、ディスク順序 GUID 以外の情報があることです。サイズ、オフセット、およびスパンされたボリューム内のオフセットを含む明確な構造があります。

上記のセクション {2.1} および {2.2} の回答を使用して、ドライブの順序を決定します。

私の 4x ディスクは、3ware 9650se コントローラーの単一の RAID5 アレイから 4x 2TB チャンクと 1x より小さいチャンクとしてエクスポートされます。各ディスクのフォーマットは次のとおりです。

/dev/sdX1 = LDM metadata partition (~1mb)
/dev/sdX2 = Reserved msoft partition (~100mb)
/dev/sdX1 = LDM data partition (~1.99TB/20GB)

'xxd -a -l 65535 /dev/sdd1 | から もっと」

0002800: 5642 4c4b 0000 000c 0000 000e 0000 0001  VBLK............
0002810: 0000 4033 0000 0031 0109 0844 6973 6b31  ..@3...1...Disk1
0002820: 2d30 3100 0000 0000 0000 0000 0000 0b00  -01.............
0002830: 0000 0000 0007 de00 0000 0000 0000 0004  ................
                     ^---^ Note 07 de (offset)
0002840: fffb f000 0108 0102 0000 0000 0000 0000  ................
         ^-------^ Note fffb f000 (size)
0002850: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0002880: 5642 4c4b 0000 000d 0000 000f 0000 0001  VBLK............
0002890: 0000 4033 0000 0031 010a 0844 6973 6b32  ..@3...1...Disk2
00028a0: 2d30 3100 0000 0000 0000 0000 0000 0b00  -01.............
00028b0: 0000 0000 0007 de00 0000 00ff fbf0 0004  ................
                     ^---^ Offset   ^--------^ Now see spanned offset
00028c0: fffb f000 0108 0103 0000 0000 0000 0000  ................
         ^-------^ note size again!
00028d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0002900: 5642 4c4b 0000 000e 0000 0010 0000 0001  VBLK............
0002910: 0000 4033 0000 0031 010b 0844 6973 6b33  ..@3...1...Disk3
0002920: 2d30 3100 0000 0000 0000 0000 0000 0b00  -01.............
0002930: 0000 0000 0007 de00 0000 01ff f7e0 0004  ................
                     ^---^ Offset   ^--------^ Now see spanned offset
0002940: fffb f000 0108 0104 0000 0000 0000 0000  ................
         ^-------^ note size again!
0002950: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0002980: 5642 4c4b 0000 000f 0000 0011 0000 0001  VBLK............
0002990: 0000 4033 0000 0031 010c 0844 6973 6b34  ..@3...1...Disk4
00029a0: 2d30 3100 0000 0000 0000 0000 0000 0b00  -01.............
00029b0: 0000 0000 0007 de00 0000 02ff f3d0 0004  ................
                     ^---^ Offset   ^--------^ Now see spanned offset
00029c0: fffb f000 0108 0105 0000 0000 0000 0000  ................
         ^-------^ note size again!
00029d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
0002a00: 5642 4c4b 0000 0010 0000 0012 0000 0001  VBLK............
0002a10: 0000 4033 0000 0031 010d 0844 6973 6b35  ..@3...1...Disk5
0002a20: 2d30 3100 0000 0000 0000 0000 0000 0b00  -01.............
0002a30: 0000 0000 0007 de00 0000 03ff efc0 0004  ................ 
                     ^---^ Offset   ^--------^ Now see spanned offset
0002a40: 17b7 d000 0108 0106 0000 0000 0000 0000  ................ 
         ^-------^ And my final drive is the smallest
0002a50: 0000 0000 0000 0000 0000 0000 0000 0000  ................

したがって、上から、データ セクションのサイズ、パーティション内のオフセット、およびスパン ボリューム内のオフセットを明確に確認できます。それでは、計算してみましょう。

Disk1:
Size of block = fffb f000 = 4294701056
Start offset = 07 de = 2014
Partition offset = 00 0000 00 = 0

Disk2:
Size of block = fffb f000 = 4294701056
Start offset = 07 de = 2014
Partition offset = 00ff fbf0 00 = 4294701056

Disk3:
Size of block = fffb f000 = 4294701056
Start offset = 07 de = 2014
Partition offset = 01ff fbf0 00 = 8589402112

Disk4:
Size of block = fffb f000 = 4294701056
Start offset = 07 de = 2014
Partition offset = 02ff fbf0 00 = 12884103168

Disk5:
Size of block = 17b7 d000 = 397922304
Start offset = 07 de = 2014
Partition offset = 03ff fbf0 00 = 17178804224

*Note: Use Excel, hex2dec() function*

これは dmraid で次のように変換されます。

# File /etc/ntfsvolume
#offset into    Size of this    Raid    Device          Start sector
# volume                        type                    in volume
0               4294701056      linear  /dev/sdd3       2014
4294701056      4294701056      linear  /dev/sdc3       2014
8589402112      4294701056      linear  /dev/sdf3       2014
12884103168     4294701056      linear  /dev/sde3       2014
17178804224     397922304       linear  /dev/sdg3       2014

これは、次の方法で直接マウントできます。

$ dmsetup create myvolume /etc/ntfsvolume
$ sudo mkdir /media/volume/
$ mount -t ntfs-3g /dev/mapper/myvolume /media/volume
$ sudo mount -t ntfs-3g -o ro /dev/mapper/myvolume /media/volume (mount read-only)

モジュールが必要です:

dmraid
ntfs-3g

警告!

読み取り/書き込みをマウントする前に、すべてのオフセット、ディスク上のサイズ、およびスパン オフセットが正しいことを絶対に確認してください。オフセットが間違っていると ntfs-3g がマウントされ、ファイルの内容が正しくなくなります。

適切な二重チェックは、Windows チェック ディスクを使用し、最後に追加情報をループすることです。割り当てられたユニットの総数に注意してください。これをブロック サイズ (私の場合は 4096) で乗算し、それを 512 (通常のセクター サイズ) で割ります。これは、報告されたウィンドウのサイズと一致する必要があります。

私のパーティション サイズは、上記のメタデータ テーブルで示されているサイズよりも 4096 バイト小さく、間違っていると報告されています。パーティション サイズは偶数に丸められると想定しています。私は2197090816を計算します.Windowsは2197090815、4096バイトブロックと言います..

参考文献

于 2012-07-20T11:40:46.453 に答える