☰

从 Windows 7 不安全删除后 NTFS 驱动器损坏

tag-icon • tag-icon windows-7 linux ntfs data-recovery
从 Windows 7 不安全删除后 NTFS 驱动器损坏

首先，介绍一下该驱动器的一些信息 - 它是一个 USB 2.0 便携式硬盘 (PQI H560)，一个分区占整个 640GB，NTFS。几乎只在 Linux（arch 和 ubuntu）上使用，但最初在 Windows 7 上格式化。

硬盘上有相当多的硬链接，因为它是一个类似时间机器的备份系统。

现在来谈谈问题本身：

今天我犯了一个错误，从 Linux 系统中取出便携式硬盘并将其插入 Windows 7 机箱。一切正常，我从硬盘中取出一部电影，它静置了大约一个小时。之后我取出硬盘（忘记卸载 :/）并将其放回 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 还算耐用。

有关数据恢复工具的提示会很棒。最好能有一些非破坏性的东西（能够获取数据，同时保留驱动器当前状态的每一部分 - 只是为了确保它不会破坏任何东西）

答案1

不安全地移除驱动器是导致你失败​​的原因。

您必须运行数据恢复来删除文件、格式​​化驱动器并将所有内容移回，或者冒险使用其中一个 Linux 工具。

此外，Windows 7 没有任何问题。您执行了不安全的删除，所以这不是 Windows 的错误。

答案2

好吧...在运行任何工具之前，我确实建议制作一个图像...如果你没有直接制作 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

我只将 lzma 的压缩级别设置为 7，因为在较慢的处理器上，9 可能需要很长时间。一旦解决了这个问题，我推荐使用 testdisk 及其姊妹应用程序 photorec。Testdisk 在一定程度上能够修复文件系统……我自己没有用过很多，但我知道有些人对它赞不绝口。Photorec 是恢复所有单个文件的最后一搏，它会查找已知文件类型逻辑数据的开始和结束点。但是，即使它可能很耗时，您也应该先尝试 ntfsfix。如果它完全破坏了任何东西，那么只需从您的映像中提取：

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

关于哪里出了问题，我只想说不要责怪任何一个操作系统，它们都对损坏它起了同等的作用。它因 Windows 操作系统未清洁而变脏，在尝试 ntfs-3g 可写入安装时，它进一步损坏，以至于 Windows 不再喜欢它。这听起来有点奇怪，但看看内核配置，ntfs 写入支持仍然被标记为实验性的，风险自负。虽然我讨厌 Windows，但这次我不能责怪它。ntfs 有点奇怪：从 Windows 未清洁卸载可以从 Windows 修复，从 linux 未清洁卸载可以从 linux 修复。使用不干净的 ntfs 分区越界通常会杀死它……抱歉，只是其中一件事。

答案3

这个问题的答案是恢复器终极版，除了一些大文件（2GB+）、日志和一些硬链接（被视为重复）的问题外，它解决了它。

此外，我越是查看日志，就越觉得 MFT 不是问题所在，至少不是 MFT 的根源。一些重复的内容不是二进制相等的，似乎是驱动器在影子复制时失败了，也许 MFT 的较深部分存在一些循环或其他非常糟糕的结构。查看日志似乎所有操作系统实现都发生了致命故障，我的意思是分段错误。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

然后它就死了。

所以，看来我遇到了一个由懒惰引起的罕见问题。供将来参考：最好的解决方法是做你应该做的事情，即卸载驱动器。也许还可以禁用外部驱动器上的卷影复制。

无论如何，恢复程序修复了它，至于失败，看起来 Windows 以某种方式导致分区处于日志系统不应该处于的状态。也许在 Linux 中安装它也起了作用，尽管我觉得不太可能，ntfs3g 不会在没有询问的情况下修复东西，通常它无论如何都无法做到，或者在系统日志中呼吁用户注意。

相关内容