无法再访问 NTFS 分区，3 个 MFT 记录已损坏，如何修复？

Question

我有一个带有一个 NTFS 分区的 2TB Seagate ST2000DM001 HDD。我几个月没用了，当我再次插入它时，这个分区莫名其妙地变得无法访问：Windows 资源管理器中出现了卷的字母，但不再识别该分区的大小，如果我尝试打开它，则会出现错误。它在存储管理器中显示为“RAW”。CHKDSK 立即放弃对其进行分析，并显示一条错误消息，指出无法确定卷的版本和状态。

但是，如果我使用 R-Studio 打开该驱动器，该分区会立即显示其正确大小，我可以打开它（甚至不需要扫描）并访问我上次正常使用时存在的所有文件，使用整个目录树，就我所见，文件的内容似乎是 100% 正确的。同样，如果我用 WinHex 打开整个驱动器，它会正确识别分区，并显示文件和文件夹及其正确内容。我还测试了 2 个碎片整理软件（仅在分析模式下）：MyDefrag 可以列出分区的内容，并为鼠标指针悬停的每个块提供有效信息（文件名、大小、LBA...）；但碎片整理程序不能。我也用DMDE打开它：像R-Studio一样，它可以立即识别分区的内容；MFT 记录 1, 2, 3 ; 这些通常对应于：$MFTMirr、$LogFile和$Volume，三个重要的系统文件，它们确实在“$MetaData”目录中丢失了。如果我回到 R-Studio，我可以看到“Metafiles”目录中也缺少这些文件。如果我用 WinHex 检查 MFT 的开头，我可以看到 MFT 记录 0 很好（它指向 MFT 本身），但随后MFT 记录 1、2 和 3 已损坏，它们用“FF”（十六进制）/“ÿ”（ASCII）填充。奇怪的是，MFT 镜像（我仍然可以使用 WinHex 找到它，使用旧的卷快照，在问题出现之前制作，并且它的位置也由 R-Studio 在其分区属性面板中指示，显然 MFT 和MFTMirr 将它们的 LBA 写入引导扇区）具有完全相同的损坏模式：第一条记录没有问题，然后接下来的三个记录填充为“FF”。

现在，我的猜测是该分区无法访问，因为缺少那三个 MFT 记录，因此找不到相应的文件。而 CHKDSK 必须至少需要这些文件才能正常运行。怎么会这样？MFT 及其镜像（实际上只是前 4 条记录的副本，但在这种特殊情况下，它应该足以解决问题，因为 3 条损坏的记录在这 4 条中）最终在同时 ？
我如何修复/重新创建那些丢失的 MFT 记录，以便“就地”修复分区，而不是提取所有文件（作为安全措施我已经这样做了），重新格式化分区，然后将它们传输回来？我可以从另一个分区复制有效记录，并更改变量值，知道模板，但到目前为止我只能识别时间戳（我可以从同一分区上的其他系统文件复制，因为它们都是在完全相同的时间），我还无法找到指示集群位置大小的字段。我还发现 $Volume 是一个常驻文件（完全位于 MFT 中），它包含分区的唯一标识符，这可能是这里最有问题的障碍：它是否必须与以前相同才能使分区正确被识别，如果是，它是否存储在系统的某个地方，或者它可以随机选择，如果是这样，是否有它必须符合的特定模式？关于 MFT 记录的基本结构的信息似乎很少，或者很难在数千页蜿蜒的论坛主题或文章中找到，范围太广，在这种情况下没有任何用处。

我在 HDDGuru 上用更多细节描述了这个问题，但没有对“我该如何修复它？”这个问题提供相关的答案。（在硬件/固件故障方面，常规贡献者知识渊博，但对于这种逻辑故障，他们似乎很快就放弃了）。
http://forum.hddguru.com/viewtopic.php?f=1&t=36969

Answer 1

所以，我设法自己解决了这个问题。我对 MFT 记录的一般结构以及我必须重新创建的 3 个损坏记录的特定结构进行了一些研究（有关详细信息，请参阅链接的 HDDGuru 线程），同时在几个有效分区上检查它们。然后基本上我将它们从有效分区复制到 WinHex 中的临时文件中，将一些与一个分区不同的键值更改为另一个分区，然后将 3072 字节文件直接复制到该分区上，运行 CHKDSK，这可以继续进行并且（在几次试验和错误）报告该卷没有错误，现在该分区可以再次正常访问。我仍然不知道它是怎么发生的，但它已经修复了！

\n

我必须更改的值是：
\n\xe2\x80\x93 时间戳：所有系统文件都具有相同的时间戳，因此我只是从损坏的第一个 MFT 记录（指向 MFT 本身）复制时间戳字段分割;
\n\xe2\x80\x93 在 DMDE 中，每条记录上都有一个名为 \xe2\x80\x9cfixup\xe2\x80\x9d 的 1 字节字段，存在于每个记录的三个不同位置，正如有人向我解释的HDDGuru 线程只是 \xe2\x80\x9ca 检查以确保记录有效且未损坏\xe2\x80\x9d 并且可以设置为任何值，只要它在所有三个实例中都相同那个领域；
\n\xe2\x80\x93 $LogFile 记录的第一个集群 LBA（由于旧的 WinHex 卷快照，我知道它位于哪里，否则我将不得不根据其标头搜索文件以获取该值；它的默认大小正好是 64MB，或 67108864 字节，在我检查的所有分区上都是相同的）；
\n\xe2\x80\x93 对于 $Volume 记录（它还包含实际的 $Volume 文件，因为该文件是 \xe2\x80\x9cresident\xe2\x80\x9d，即完全包含在其 MFT 记录中），我必须找到卷的原始 16 字节 ID（或 \xe2\x80\x9c 对象标识符\xe2\x80\x9d），这是最棘手的部分；经过一些不成功的尝试后，我在 \xe2\x80\x9ctracking.log\xe2\x80\x9d 文件中发现了该值，该文件位于 \xe2\x80\x9cSystem Volume Information\xe2\x80\x9d 目录中（我首先检查了该文件对于有效分区，该值与 $Volume 中出现的值匹配，因此我从损坏的分区上的 \xe2\x80\x9ctracking.log\xe2\x80\x9d 复制了相应的字段，并将其粘贴到卷 ID 字段中以 $Volume 为单位）；
\n\xe2\x80\x93 也在 $Volume 中，我更改了卷的名称，与以前具有相同的名称，但这不是必需的，我可以保留其他分区的名称并稍后更改它一旦再次可以访问，就会在卷的属性中打开它（实际上我在这里使用了一个小技巧：我从名为 \xe2\x80\x9cTEMP\xe2\x80\x9d 的分区复制了 $Volume 记录的末尾，然后，我没有像之前调用分区那样使用 \xe2\x80\x9cStockage\xe2\x80\x9d 更改该名称，而是放置 \xe2\x80\x9cStoc\xe2\x80\x9d，以便它具有相同数量的字符，以避免意外的偏移，并确保 \xe2\x80\x9cused size\xe2\x80\x9d 值匹配，因为我还没有完全理解记录的结构）；
\n\xe2\x80\x93 由于我更改了卷的名称，实际使用的文件记录长度不同，所以我不得不更改\xe2\x80\x9所使用的大小\xe2\x80对应的字段\x9d 来反映这一点并保持一致性（我将 \xe2\x80\x9cused 大小 \xe2\x80\x9d 与名为 \xe2\x80\x9cTEMP\xe2\x80\x9d 的分区中的大小相同）；
\n\xe2\x80\x93 在 $Volume 记录的开头还有另一个不同的值，在 DMDE 中称为 \xe2\x80\x9cLSNlo\xe2\x80\x9d：基于我的研究 \xe2\x80\ x9cLSN\xe2\x80\x9d 代表 \xe2\x80\x9c$LogFile Sequence Number\xe2\x80\x9d，它是对 $LogFile 中记录的关于 $MFT 中给定文件记录的最后更改的引用，这对于一致性并不重要，无论如何，我发现 $LogFile 的大小受到限制，它经常 \xe2\x80\x9cpurges\xe2\x80\x9d 旧记录，所以，因为我没有使用过它在几个月的驱动器中，与擦除之前的值相对应的记录已被删除，所以我只是在该字段中添加了零。[2022/04/09] {重新阅读这篇文章，并对其进行编辑主要是为了修复拼写错误，我不确定我在该部分中写的内容 \xe2\x80\x94 如果驱动器没有被使用了几个月后，$LogFile 条目不太可能被 \xe2\x80\x9cpurged\xe2\x80\x9d... 但无论如何，该值并不重要，因为它没有它就可以工作。根据过去几年这两个帖子获得的票数，如果它可以帮助一些人，我很高兴。}

\n\n

@DrMoishe Pippik：作为一种安全措施，在尝试就地修复之前，我使用 R-Studio 将全部内容提取到另一个驱动器。我还对前 5GB 进行了部分备份（这足以包含所有相关的文件系统结构 \xe2\x80\x93，尽管应该强调的是，它并不总是足以获取整个 MFT，我是在艰辛的道路！）。我还没有尝试在另一台计算机上访问该驱动器，但我不知道它会有什么不同（无论如何在 Windows 系统上 \xe2\x80\x93 也许它仍然可以在一台计算机上被识别和访问） Linux 系统），因为这三个 MFT 记录在 WinHex 中似乎已被有效擦除，并且重新启动后问题仍然存在。

\n

@cybernard：我尝试了 TestDisk，这是我检查 SMART 状态后的第一个想法（过去和现在仍然很好）：它确实找到了分区，并且可以列出文件（就像我提到的其他软件一样），但是它无法解决问题，因为在 MFT 损坏的情况下它所能做的就是通过从 $MFTMirr 复制前 4 条记录来修复它们，但这里这三个损坏的记录也在 $MFTMirr 中损坏，完全相同方式。

\n

@Andrea Lazzarotto：根据我的观察，$MFTMirr 始终位于扇区 16，因此位于卷的最开始处，远在实际 $MFT 之前，默认情况下，$MFT 大约在 3GB 标记附近。CHKDSK 可能不起作用，因为 $MFTMirr 也已损坏，因此它无法访问显然至关重要的 $Volume 文件，该文件也已被擦除，因为它是其 MFT 记录的一部分。[2022/04/09] {Windows 7 如此，很可能 8-10-11 也是如此。$MFT 和 $MFTMirr 区域的默认位置与用于格式化分区的 Windows 版本相关联，并且在操作系统的历史上已多次更改。}

\n