web-dev-qa-db-ja.com

LinuxにマルチディスクWindowsNTFS RAID /論理ドライブをマウントするにはどうすればよいですか？

職場に古いWindowsラップトップの500GBハードドライブが2台あります。上司から、可能であればコンテンツをファイルサーバーにコピーするように依頼されましたが、データが失われることは絶対にないという警告があります。

通常はバックアップで十分ですが、これはバックアップのようなものがより厳密に保持されていなかった操作の初期の頃からのものであり、この男は悪名高いほど組織化されていなかったので、バックアップが最も充実しているかどうかはわかりません-最新の（または合理的に最新の）コンテンツ。

私が最初にしたことは、ddrescueを使用して画像を作成することでした。パーティションテーブルがエラーなしでコピーされたドライブ、および他のドライブはエラーにより最大150KiBを失いました。イメージは、losetupを使用して_/dev/loop1_および_/dev/loop2_に読み取り専用でマウントされました。 _fdisk -l_は次のことを示しています。

_Disk /dev/loop1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop2: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x87afa6ad

Device       Boot      Start        End    Sectors   Size Id Type
/dev/loop2p1            2048   31459327   31457280    15G 27 Hidden NTFS WinRE
/dev/loop2p2 *      31459328   31664127     204800   100M 27 Hidden NTFS WinRE
/dev/loop2p3        31664128 1191071167 1159407040 552.9G  7 HPFS/NTFS/exFAT
/dev/loop2p4      1191071168 1953533951  762462784 363.6G  7 HPFS/NTFS/exFAT
_

パーティションサイズは、これがRAIDアレイまたはWindows論理ドライブであることを示唆しているようで、blkidを使用したクイックチェックでは、ドライブタイプが_isw_raid_member_であることが示されました。 _mdadm -v --assemble /dev/md0 /dev/loop2 /dev/loop1_を使用して配列をアセンブルしようとすると、次の出力が生成されました。

_mdadm: looking for devices for /dev/md0
mdadm: Cannot assemble mbr metadata on /dev/loop2
mdadm: /dev/loop2 has no superblock - Assembly aborted
_

ドライブをマウントするか、より多くの情報を取得しようとした他のことは次のとおりです。

  • _mount /dev/loop2 <mount point>_：_unknown filesystem type 'isw_raid_member'_で失敗しました
  • _mount -t_ NTFSおよびexFATの場合：ファイルシステムが見つかりません
  • _mount /dev/loop2p[1234]_：_Special device <dev> does not exist_
  • _mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/loop[21]_：_/dev/loop2_は、デバイスがなく、作成日が1970年1月1日00:00:00のRAID0アレイの一部であるように見えると述べています
  • _mdadm -E /dev/loop[12]_：_/dev/loop1_でmdスーパーブロックが検出されなかったことを示し、_aa55_のパーティションと_/dev/loop2_のMBRマジックナンバーを出力します。
  • _file -s /dev/loop1_：_/dev/loop1: data_を出力します
  • _file -s /dev/loop2_：基本的にDOS/MBRブートセクターであると言ってテキストのブロックを吐き出し、パーティションのオフセット/サイズの生の数値を示します。

  • mount -t ntfs -o ro,offset=$((512*2048)) /dev/loop2 /mnt/partition1：

    _NTFS signature is missing
Failed to mount '/dev/loop3': Invalid argument
The device '/dev/loop3' doesn't seem to have a valid NTFS
_

    いいえ、その_3_をタイプミスしませんでした。それがどこから来たのか見当がつかない。

失敗したソフトウェアRAIDの回復 も調べましたが、これはLinuxで回復中のすでに動作しているLinuxアレイのようです（言うまでもなく、かなり頭を悩ませています）。

これらのイメージを安全にマウントするためにできることはありますか？

linuxhard-driveraiddata-recoverylogical-drive
7
awksp

注：OPがコメント、試行錯誤を通じて助けを得た後、私はこの回答を書いています。他のユーザーを念頭に置いて、私は答えをより広く、もう少し一般的にしています。

これらの2つのディスクが一緒に機能した場合、

  1. ミラーリングされたRAID1スタイル。
  2. または連結されたJBODスタイル。
  3. またはストライプ、RAID0スタイル。

ケースは、最も扱いやすいものから順に並べられています。それらを区別する方法と、最終的にパーティションをマウントするためにそれらを処理する方法を説明します。

マウントは、正しく行われることが確実になるまで、最初に-o roを使用して実行する必要があります。場合によっては、mountが成功し、マングルされたディレクトリ構造やスクランブルされたファイルにアクセスできるようになることがあります。非常識なデータやメタデータは、正しく理解できなかったことを示しています。読み取り専用をマウントすると、イメージに害を及ぼすことがなくなります。

1.ミラーリングされたRAID1スタイル

この場合、正常であれば、両方のディスクに同じデータが含まれている必要があります。両方に同じ有効なパーティションテーブルが含まれている必要があります。 /dev/loop2として持っているイメージだけがパーティションテーブルを報告します。これはおそらく

  • そもそもミラーリングされていませんでした
  • または、他のディスクで言及したこれらのエラーは、パーティションテーブルがある場所で発生しました（DOSパーティションテーブルの場合、MBR、つまり最初はセクター番号0）。

ただし、この場合、RAID1の可能性がほとんどない大きな手がかりが1つあります。fdiskは、単一のディスクに正確に976773168セクターがあると言っていますが、4番目のパーティションの最後のセクターは1953533951です。これはほぼ2倍であり、ミラーリングされていない2つのディスクにパーティションレイアウトが生成されることを示しています。

しかし、ディスクが2倍の大きさで、上記の手がかりが当てはまらなかったとしましょう。ミラーリングされたディスクを処理できると思われる場合は、エラーなしで取得したイメージを処理し、他のイメージはそのままにしておきます。次のようにパーティションをマウントしてみてください。

mount -o ro,offset=$((512*2048)) /dev/loop2 /mnt/partition1
mount -o ro,offset=$((512*31459328)) /dev/loop2 /mnt/partition2
mount -o ro,offset=$((512*31664128)) /dev/loop2 /mnt/partition3

など。losetupを使用して/dev/loop2を取得することはできませんが、ファイルパスを直接指定すると、mountは独自にループデバイスを作成し、これを適切に処理する必要があります。

mount -o ro,offset=$((512*2048)) /path/to/the/image2.raw /mnt/partition1

2.連結されたJBODスタイル

JBODを構築しているディスクがMBRを使用してパーティションテーブルを格納している場合、fdiskは最初のディスクでのみそれを見つけます。他のディスクは、何も報告しないか、いくつかの異常なパーティションテーブルを報告する場合があります。最初ではないディスクから正常に見えるパーティションテーブルを取得する可能性は非常に低いですが、それでもこのパーティションテーブルは何の意味もありません。

JBODを構築するディスクがGPTを使用してパーティションテーブルを格納する場合、gdiskなどのツールは、最初のディスクでプライマリテーブルを検索し、最後のディスクでセカンダリ（バックアップ）テーブルを検索します。

2つのイメージがあり、1つはDOSパーティションテーブル（つまり、MBRのパーティションテーブル）を報告し、もう1つはパーティションテーブルを報告しません。 JBODを作成する場合は、/dev/loop2に対応するものが最初になります。

あなたの場合、パーティション1と2は、JBODの最初のディスクに完全に収まるほど小さいです。ソール/dev/loop2から適切なオフセットでそれらをマウントすることを試みることができます。これにより、正常なファイルシステムにアクセスできる場合は、JBODがおそらく適切なセットアップであることがわかります。すべてのパーティションにアクセスするには、イメージを連結する必要があります。

私のこの答え 結果をディスクに書き込まずに画像を連結する方法を提供します。あなたの場合、手順は次のようになります。

  1. dmsetup create mydisk
  2. タイプ0 976773168 linear /path/to/the/image2.raw 0 Enter
  3. タイプ976773168 976773168 linear /path/to/the/image1.raw 0 Enter
  4. ヒット Ctrl+D

結果のデバイスは/dev/mapper/mydiskになります。適切なoffset=…を使用してパーティションをマウントしてみてください。

デバイスを破棄するには、dmsetup remove mydiskを呼び出します。

3.ストライプ、RAID0スタイル

JBODと同様に、RAID0を構築しているディスクがMBRを使用してパーティションテーブルを格納している場合、fdiskは最初のディスクでのみそれを検出します。他のディスクは、何も報告しないか、いくつかの異常なパーティションテーブルを報告する場合があります。最初ではないディスクから正常に見えるパーティションテーブルを取得する可能性は非常に低いですが、それでもこのパーティションテーブルは何の意味もありません。

RAID0を構築するディスクがGPTを使用してパーティションテーブルを格納する場合、状況は複雑になります。ストライプサイズの大きさに応じて、最初のディスクからプライマリパーティションテーブルを取得する場合としない場合があります。最後のディスクからセカンダリ（バックアップ）パーティションテーブルを取得する場合としない場合があります。 （読み取りエラーが発生しない限り）最初のディスクからレガシーMBRを取得する必要があります。

2つのイメージがあり、1つはDOSパーティションテーブル（つまり、MBRのパーティションテーブル）を報告し、もう1つはパーティションテーブルを報告しません。 RAID0を作成する場合は、/dev/loop2に対応するものが最初になります。わからないのはストライプサイズです。一般に、それを知る確実な方法はありません。一般的な値を試して、結果を分析する必要があります。

イメージをインターリーブして仮想デバイスを作成する手順は次のとおりです。

  1. dmsetup create mydisk
  2. タイプ0 1953546336 striped 2 256 /dev/loop2 0 /dev/loop1 0 Enter
  3. ヒット Ctrl+D

結果のデバイスは/dev/mapper/mydiskになります。 256という数字は128KiBのストライプサイズを意味し、正しく推測する必要があります。一般に、dmsetupより前のGPTで発生する可能性のある問題に関係なく、ストライプサイズが正しいと推測される場合、gdisk -l /dev/mapper/mydiskは有効なパーティションテーブルを返すはずです。間違っていると思われる場合は、パーティションテーブルが有効な場合と無効な場合があります。有効と思われる場合は、適切なoffset=…値を使用してすべてのパーティションをマウントしてみてください。

あなたの場合、パーティションテーブルは確かに/dev/loop2から取得したものになります。

推測を間違えてもマウントできる場合がありますが、ファイルはスクランブルされることに注意してください。この場合、umount、dmsetup remove mydiskを呼び出し、256ではなく別の値でdmsetup create…を繰り返します。試す数：8、16、32、64、128、256、おそらく他の2の累乗。検証可能なコンテンツ（MP3などのメディア、ジッターなしで再生されますか？）または正式な構造（PDFなど、エラーなしで開きますか？）を含むファイルを読み取って、推測が正しいかどうかを確認します。 rightストライプサイズよりも小さいファイルは、推測が間違っていることを示していない可能性があるため、テキストファイルだけでなく700MBのaviを使用する必要があります数KBの。

デバイスを破棄するには、dmsetup remove mydiskを呼び出します。

3
Kamil Maciorowski