我有一个带有一个 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 是一个常驻文件（完全位于 …
我正在寻找一个 Linux 等价的 command Robocopy /CREATE，它重新创建一个完整的空文件树，其中包含源中文件夹和文件的所有属性，文件内容除外。据说 Rsync 相当于用于一般文件同步目的的 Robocopy，但似乎没有类似的选项。
我正在从 4TB 硬盘驱动器恢复数据，主分区格式为 Ext4，到目前为止，我可以使用 HDDSuperClone 克隆 47%，直到它开始遇到严重问题，但在恢复驱动器上仍然无法访问该分区，而R-Studio 和 DMDE 等恢复软件无法重建原始元数据结构，并且驱动器当前的降级条件可能无法恢复更多有用的数据。
因此，由于原始驱动器仍然可以安装在 Lubuntu 上（尽管有困难），如果我不得不求助于“原始文件雕刻”，即使用检测文件签名的工具扫描恢复的数据并批量提取所有检测到的文件（我我主要使用 R-Studio 和 Photorec 来达到这个目的），我想至少为驱动器的所有者提供一种比没有参考的从头开始更方便地整理这种混乱的方法。
显然，在这种情况下，我正在寻找的命令应该快速进行并且只分析几个关键的文件系统结构，而不涉及对分区的彻底扫描，这只会进一步磨损该驱动器。