我有一块 2TB 的 Seagate ST2000DM001 HDD，上面有一个 NTFS 分区。我已经好几个月没用它了，当我再次插入它时，这个分区莫名其妙地变得无法访问：卷的字母出现在 Windows 资源管理器中，但分区的大小不再被识别，如果我尝试打开它，就会出现错误。它在存储管理器中显示为“RAW”。CHKDSK 立即放弃分析它，并显示一条错误消息，称它无法确定卷的版本和状态。
但是，如果我用 R-Studio 打开该驱动器，分区会立即显示其正确大小，我可以打开它（甚至不需要扫描）并访问上次正常使用时存在的所有文件，以及整个目录树，而且据我所知，文件的内容似乎 100% 正确。同样，如果我用 WinHex 打开整个驱动器，它会正确识别分区，并显示文件和文件夹及其正确的内容。我还测试了 2 个碎片整理软件（仅在分析模式下）：MyDefrag 可以列出分区的内容并提供鼠标指针悬停在每个块上的有效信息（文件名、大小、LBA……）；但 Defraggler 不能。我也用 DMDE 打开它：与 R-Studio 一样，它可以立即识别分区的内容；它还会显示有关MFT 记录 1、2、3；这些通常对应于：$MFTMirr，$日志文件和$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
答案1
因此，我设法自己解决了这个问题。我研究了 MFT 记录的一般结构，以及我必须重新创建的 3 条损坏记录的具体结构（有关详细信息，请参阅链接的 HDDGuru 线程），同时在几个有效分区上检查了它们。然后，我基本上将它们从有效分区复制到 WinHex 中的临时文件中，更改了一些分区间不同的键值，然后将 3072 字节文件直接复制到分区上，运行 CHKDSK，它可以继续，并且（经过几次试验和错误）报告卷没有错误，现在该分区可以正常访问了。我仍然不知道它是怎么发生的，但它已经修复了！
我需要更改的值包括：
- 时间戳：所有系统文件都有相同的时间戳，因此我只需从损坏分区上的第一个 MFT 记录（指向 MFT 本身）复制时间戳字段即可；
- DMDE 中每个记录上都有一个 1 字节的字段，称为“fixup”，每个记录中有三个不同的位置，正如有人在 HDDGuru 线程上向我解释的那样，这只是“检查以确保记录有效且未损坏”并且可以设置为任何值，只要它在该字段的所有三个实例中都相同即可；
- $LogFile 记录的第一个群集 LBA（我通过旧的 WinHex 卷快照知道它的位置，否则我必须根据其标头搜索文件才能获取该值；它的默认大小正好是 64MB，即 67108864 字节，在我检查的所有分区上都是相同的）；
– 对于 $Volume 记录（其中还包含实际的 $Volume 文件，因为该文件是“常驻”的，即完全包含在其 MFT 记录中），我必须找到卷的原始 16 字节 ID（或“对象标识符”），这是最棘手的部分；经过几次不成功的尝试后，我在位于“系统卷信息”目录中的“tracking.log”文件中找到了该值（我首先检查了该文件是否存在有效分区，该值与 $Volume 中显示的值相匹配，因此我从损坏分区上的“tracking.log”中复制了相应的字段，并将其粘贴到 $Volume 中的卷 ID 字段中）；
– 同样在 $Volume 中，我将卷的名称更改为与之前相同的名称，但这不是必需的，我可以保留其他分区中的名称，稍后在卷属性中更改它，一旦它再次可访问（实际上我在这里使用了一个小技巧：我从名为“TEMP”的分区复制了 $Volume 记录的末尾，然后，我没有像之前一样将该名称更改为“Stockage”，而是输入了“Stoc”，这样它就会有相同的字符数，以避免意外的偏移，并确保“已用大小”值匹配，因为我还不完全了解记录的结构）；
– 由于我更改了卷的名称，实际使用的文件记录的长度不同，因此我必须更改与“已用大小”相对应的字段以反映这一点并保持一致性（我输入了与“TEMP”分区中相同的“已用大小”）；
– 在 $Volume 记录的开头还有另一个不同的值，在 DMDE 中称为“LSNlo”：根据我的研究，“LSN”代表“$LogFile 序列号”，它是对 $LogFile 中记录的有关 $MFT 中给定文件记录的最后一次更改的引用，它对于一致性并不重要，而且我发现 $LogFile 的大小有限，它会定期“清除”旧记录，因此，由于我几个月没用过那个驱动器了，所以在它被擦除之前对应的值记录已被删除，所以我只是在该字段中填了零。[2022/04/09]{重读这篇文章，并主要为了修正一个拼写错误而对其进行编辑，我不确定我在那部分写了什么——如果驱动器几个月没有使用过，$LogFile 条目不太可能被“清除”……但无论如何，该值并不重要，因为没有它它也能工作。而且我很高兴它能帮助一些人，根据这两篇文章在过去几年中获得的投票数量。}
@DrMoishe Pippik：为了安全起见，在尝试就地修复之前，我用 R-Studio 将所有内容提取到另一个驱动器。我还对前 5GB 进行了部分备份（这足以包含所有相关的文件系统结构 - 虽然应该强调的是，这并不总是足以获得整个 MFT，我经历了痛苦才学会的！)。我还没有尝试在另一台计算机上访问该驱动器，但我看不出会有什么不同（无论如何在 Windows 系统上 - 也许在 Linux 系统上它仍然可以被识别和访问），因为这三个 MFT 记录在 WinHex 中似乎已被有效擦除，并且重启后问题仍然存在。
@cybernard：我尝试了 TestDisk，这是我在检查 SMART 状态（过去和现在都很好）后首先想到的办法之一：它确实找到了分区，并且可以列出文件（就像我提到的其他软件一样），但它无法解决问题，因为在 MFT 损坏的情况下它所能做的就是通过从 $MFTMirr 复制前 4 条记录来修复它们，但这里这三个损坏的记录也在 $MFTMirr 中损坏，方式完全相同。
@Andrea Lazzarotto：根据我的观察，$MFTMirr 始终位于扇区 16，因此位于卷的最开始，远早于实际的 $MFT，默认情况下约为 3GB。CHKDSK 可能不起作用，因为 $MFTMirr 也已损坏，因此它无法访问看似至关重要的 $Volume 文件，该文件也被擦除了，因为它是其 MFT 记录的一部分。[2022/04/09]{这适用于 Windows 7，很可能也适用于 8-10-11。$MFT 和 $MFTMirr 区域的默认位置与用于格式化分区的 Windows 版本相关，并且在操作系统的历史上已经发生过多次变化}