web-dev-qa-db-ja.com

Windows7からの安全でない取り外し後にNTFSドライブが損傷した

まず、ドライブに関するいくつかの情報-それはUSB 2.0ポータブルハードドライブ（PQI H560）であり、1つのパーティションがすべての640GB、NTFSにまたがっています。 Linux（Archおよびubuntu）でほぼ独占的に使用されますが、最初はWindows7でフォーマットされています。

ハードドライブはタイムマシンのようなバックアップシステムであったため、かなり多くのハードリンクがあります。

そして今、問題自体：

今日、私はLinuxシステムからポータブルハードドライブを取り出し、それをWindows7ボックスに差し込むという間違いを犯しました。すべてがうまくいきました、私はドライブから映画を撮りました、そしてそれは1時間かそこらの間休眠していました。その後、ドライブを取り出し（アンマウントするのを忘れた：/）、Linuxに戻しました。

残念ながら、次のエラーが発生しました。

[49162.611858] mount.ntfs[15397]: segfault at 7fff19cb1fe8 ip 00007f9fca88de4e sp 00007fff19cb1fa0 error 6 in libntfs-3g.so.79.0.0[7f9fca87f000+42000]

わかりました。LinuxのNTFSサポートはあまり良くないので、Windowsに戻ってスキャンディスクなどを実行しました。ああ、そうですね：

You need to format the disk in drive F: before you can use it.

Do you want to format it?

いいえ、しません。

右クリック-> [ツール]-> [今すぐ確認]（chkdskですよね？）：

The disk check could not be performed because Windows can't access the disk.

おなじみのLinuxに戻る、fdisk -lはNTFSファイルシステムを検出しますが、fsckまたはntfsfixを実行することを少し恐れています。

私が言ったように、Linux NTFSのサポートは十分で、欠けています。おそらく、パーティションのddを別のドライブに実行してそこで実験しようとしますが、現在、そのためのハードウェアを持っていません。

なぜそれがそれほどひどく壊れたのか考えはありますか？ NTFSは耐久性があると思いました。

データ復旧ユーティリティに関するヒントは素晴らしいでしょう。非破壊的なものがある場合に最適です（ドライブのすべてのビットを現在の状態に保ちながらデータを取得できます-何も壊れないことを確認するためだけに）

windows-7linuxntfsdata-recovery
4
Krzysztof Bociurko

この問題への答えは、いくつかの大きなファイル（2GB +）、ログ、およびいくつかのハードリンク（重複として扱われる）の問題を除いて、修復家の究極でした。これにより修正されました。

また、ログから見るほど、MFTは問題ではなく、少なくともMFTのルートではないように見えました。複製されたものの中には、2値が等しくないものもあり、ドライブがシャドウコピーで失敗したようです。おそらく、MFTのより深い部分にループやその他の非常に悪い構造がありました。ログを見ると、すべてのOS実装が致命的に失敗したように見えます。つまり、segfaultingです。 MacOS Xからの興味深いログ：

Interval Since Last Panic Report:  472 sec
Panics Since Last Report:          2
Anonymous UUID:                    D89B5624-FF95-48B5-8F55-0987EA2D2466

Sun Jun 26 18:02:46 2011
panic(cpu 0 caller 0x6e085e4a): "ntfs_map_runlist_nolock(): Called for $MFT/$DATA!\n"@/SourceCache/ntfs/ntfs-65.5/kext/ntfs_attr.c:245
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
 ...
  Kernel Extensions in backtrace (with dependencies):
     com.Apple.filesystems.ntfs(3.4)@0x6e05a000->0x6e0b9fff

BSD process name corresponding to current thread: mount_ntfs

そして、それは死にました。

だから、私は怠惰によって引き起こされる非常にまれな問題を抱えていたようです。将来の参考のために：最善の修正は、必要なことを実行すること、つまりドライブをアンマウントすることです。おそらく、外付けドライブのシャドウコピーも無効にします。

とにかく、restorerはそれを修正しました、そして失敗については、ウィンドウが何らかの形でジャーナリングシステムが入ってはならない状態でパーティションを残しているように見えます。質問せずに問題を修正しないでください。通常、syslogでユーザーの注意を引くことはできません。

1
Krzysztof Bociurko

ドライブの安全でない取り外しはあなたの失敗でした。

データ復旧を実行してファイルを取り出し、ドライブをフォーマットしてすべてを元に戻すか、Linuxツールの1つでリスクを冒す必要があります。

また、Windows 7には何の問題もありません。安全でない削除を実行したので、Windowsのせいではありません。

3
user3463

ええと...ツールを実行する前に、イメージを作成することをお勧めします...そして、まっすぐなddイメージ用のハードウェアがない場合は、それをlzmaにパイプして、可能な限り圧縮してみてください。

dd if=/dev/sdb bs=512k |lzma -7 -c - >ntfs.img.lzma

Sdbを何にでも置き換えることができます...それが見下すように聞こえる場合は、意図的ではありませんでした。あなたの投稿から判断すると、あなたはddの要点を知っています。私のように焦っている場合は、それをpvにパイプして、プログレスバーを取得する必要があります。

dd if=/dev/sdb bs=512k |pv |lzma -7 -c - >ntfs.img.lzma

遅いプロセッサでは9が永遠にかかる可能性があるため、lzmaの圧縮レベルを7に設定しただけです。それが邪魔にならないようになったら、testdiskとその姉妹アプリケーションphotorecをお勧めします。 Testdiskは、ある程度ファイルシステムの修復が可能です...私自身はあまり使用していませんが、それについて絶賛している人もいます。 Photorecは、個々のファイルをすべて回復するための最後の努力であり、既知のファイルタイプの論理データの開始点と終了点を探します。ただし、時間がかかる場合でも、最初にntfsfixを試す必要があります。それが何かを完全に破壊する場合は、画像からプルするだけです。

unlzma -c ntfs.img.lzma |pv |dd of=/dev/sdb bs=512k

そして、何が悪かったのかについて簡単に考えてみてください。どちらのOSでもそれを非難しないでください。どちらも、それを損傷するのに同じ役割を果たしました。それはWindowsOSの汚れたプルで汚れていて、ntfs-3gの書き込み可能なマウントを試みたところ、Windowsがそれを気に入らなくなるまでさらに損傷しました。これは少し奇妙に聞こえるかもしれませんが、カーネル構成を調べてください。ntfs書き込みサポートは、まだ実験的であり、自己責任であるとラベル付けされています。私はWindowsが嫌いですが、今回はそれを責めることはできません。 ntfsの奇妙な点：Windowsからの汚れたumountはWindowsから修復可能であり、Linuxからの汚れたumountはlinuxから修復可能です。汚れたntfsパーティションで一線を越えると、通常はそれを殺してしまいます... sry、それらの1つにすぎません。

1
darkdragn