HPFS/NTFS(ブート可能)パーティションとしてフォーマットされた古いハードドライブの内容を読みたい。起動可能な部分が違いを生むかどうかはわかりません。ドライブをマウントしようとしましたが、できません。このドライブはどうやって読むことができますか?
Sudo fdisk -l
を使用すると、ドライブは次のように表示されます。
:~$ Sudo fdisk -l
Device Boot Start End Sectors Size Id Type
/dev/sdf1 * 63 488392064 488392002 232.9G 7 HPFS/NTFS/exFAT
mount
を使用してみる:
:~$ Sudo mount /dev/sdf1 /mnt/ntfs1
mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
ntfs-3g
;を使用してみてください。
:~$ Sudo ntfs-3g /dev/sdf1 /mnt/ntfs1
NTFS signature is missing.
Failed to mount '/dev/sdf1': Invalid argument
The device '/dev/sdf1' 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?
編集:
mount -t exfat
を使用してみる:
:~$ Sudo mount -t exfat /dev/sdf1 /mnt/ntfs1
Fuse exfat 1.1.0
ERROR: exFAT file system is not found.
fsck
レポート:
:~$ Sudo fsck -f /dev/sdf1
fsck from util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdf1
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
開始するには、NEVER知らないときにパーティションでfsck
を実行しますそうすることは正しい行動です。問題は、fsck
は修復ツールであるため、ディスクにデータを書き込む可能性が高いことです。あなたのケースでは、ディスク上でどのファイルシステムが使用されているかを知る前にそれを適用しました。これは非常に危険です。修復ツールが混乱し、問題が悪化になった可能性があるためです。このような結果はほとんどありませんが、可能です。あなたはおそらく/に害はありませんでしたが、fsck
を使用してディスクにさらにダメージを与えた可能性はわずかです。
ディスク上のファイルシステムの種類を知るには、次のようにblkid
を使用します。
$ Sudo blkid /dev/sdb3
/dev/sdb3: UUID="493344495F520D15" TYPE="ntfs"
もちろん、出力は異なる可能性がありますが、この例ではNTFSボリュームを示しています。出力がまったく得られない場合、それはblkid
がファイルシステムを識別できなかったことを意味し、ひいては非常にひどく損傷していることを意味します。出力はあるがTYPE=
がntfs
以外の何かを示している場合、それはNTFSボリュームではないことを意味します。出力が明らかで、そこから先に進むこともできますし、詳細を投稿してアドバイスを求める必要があるかもしれません。
ファイルシステムがわかっている場合は、ファイルシステム固有のマウントツールを使用し、場合によっては修復ツールを使用できます。可能性のあるツール(NTFSおよびexFAT)を使用してマウントしようとしています。パーティションのタイプコード(0x07)は、かつてHPFSで一般的に使用されていましたが、ディスクがOS/2で使用されていて、Windows 7で使用されていた場合にのみそうでした。
潜在的に破壊的な修復ツールを使用する前に、次のように低レベルのバックアップを行うことをお勧めします。
Sudo dd if=/dev/sdf1 of=/path/to/lots/of/space/sdf1.img
このコマンドは、/dev/sdf1
をsdf1.img
の/path/to/lots/of/space/
ファイルにバックアップします。パーティション全体を保持するのに十分な空き領域があることを確認してください-約233 GiB。このバックアップを作成すると、修復ツールが問題を悪化させる場合に、場合によっては回復する方法が得られます。
私の考えでは、ディスクはNTFSを使用していますが、ディスクが破損しているか、正しくシャットダウンされていません。その場合、を最初にWindowsツールで修復する必要があります。 Linux ntfsfix
ユーティリティの名前は不十分です。最小限のチェックのみを行い、Windowsで注意が必要なディスクにフラグを立てます。 fsck
にはNTFSのLinuxサポートがないため、NTFSボリュームでfsck
を使用しないでください。
また、もっとエキゾチックなことが起こっていることも考えられます。たとえば、ディスクがRAIDアレイで使用されている可能性があります。その場合、同じアレイの他のディスクなしでは何も回復できない可能性があります。 (詳細は、使用されるRAIDのタイプとその他の詳細に依存します。)
最悪のシナリオでは、 PhotoRec を使用して個々のファイルを回復できる場合があります。
もう1つのポイント:コメントで、GPartedを/dev/sdf1
で実行したと言いました。これは無意味です-そして潜在的に危険ですらあります。 /dev/sdf1
はパーティションですが、GPartedは whole disk で使用するためのものです。つまり、/dev/sdf
です。
私の場合、Windows 10 bitlockerがハードドライブをロックしているため、この問題はdislockerを使用して解決されました。