两天前，我开始恢复一个 1TB 的故障硬盘，别人把它交给我，希望我能以便宜的价格挽救其中的大部分。
起初，它表现不稳定，经常突然断开连接并发出可怕的噪音，复制速度在每秒几 KB 到每秒 50MB 之间变化（那天天气很热，我试图在它下面放一个笔记本电脑散热垫，上面放一个散热块，以防止它过热，我大约每小时更换一次）。然后，在第一天晚上，它变得更加稳定，但平均复制速度显著下降到大约 3-4MB/s。现在，在恢复了 250GB 后，我的平均速度下降到大约 400KB/s，这太慢了（至少它似乎没有进一步下降）。
我的问题是：
- 我正在将恢复操作执行到 NTFS 分区，根据我在这个过程的后期所读到的内容（这本法国指南)，因为它可能会大大减慢恢复速度。这（仍然）是真的吗？如果是，为什么？
- 或者这已经成为过去，当时 Linux 的 NTFS 驱动程序还不够成熟？（我正在使用最新的 Knoppix live DVD，复制到存储卡上，因为它无法从 DVD-RW 成功启动。）
- 在这个阶段将分区转换为 Ext4 等原生 Linux 格式是否值得？我的意思是，这会显著提高复制速度吗？
- 或者，在第一次检查后，大多数“健康”扇区已经恢复，出现故障的驱动器出现这样的减速是正常的吗？（SMART 参数正在恶化，“整体健康自我评估测试结果”从“通过”变为“失败”，重新分配的扇区数量从 144 个增加到 1360 个。）
- 我还能做些什么来提高恢复率和/或恢复速度？
- 有
ddrescue哪些选择我可以尝试并能获得真正的好处？
我使用以下命令进行了第一次运行：
ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log
（-n&-N开关据称可以绕过抓取和修剪阶段 - 虽然我不确定程序在流程的哪个阶段尝试执行这些操作，以及绕过它们是否真的有用。然后我指定了每秒 500000 字节的最小复制速度，并将“读取错误时跳过的初始大小”的值指定为 1MB，尝试尽快复制仍然健康或易于访问的区域。 代表-u“单向”：在之前使用另一块硬盘进行恢复时，使用开关反向复制-R似乎可以改善情况，但使用这块硬盘似乎会造成严重破坏，并且使用该开关显然更稳定。）
现在，在它完成一次传递后，我删除了大部分这些参数，只保留了-u。我尝试了-d某个时候的开关（“使用直接磁盘访问”），但什么都没有复制，“错误大小”增长得非常快。
答案1
完成我上面的评论（对正式的不便/不一致表示抱歉）：我会说这是值得的，尽管我不太明白为什么。第二次尝试，恢复到 Ext4 分区，开始时复制速度明显更高（平均约 90 MB/s，而我第一次尝试恢复到 NTFS 分区时最多只有 50 MB/s），没有错误，甚至没有减速。但是，在复制了大约 165 GB（比以前早）之后，它变得非常不稳定并且速度变慢，再次发出咔嗒声和呼呼声（这是一个非常热的时期，没有帮助——我尝试尽可能地冷却它，在下面使用笔记本电脑散热垫并在其上放置冷冻包，每小时左右更换一次）；我一次又一次地尝试（有时它会恢复到 120 MB/s 的速度几秒钟然后又回到 0），但一段时间后我不得不放弃它。
这是ddrescueview第一次恢复的地图：
有一个有趣的模式，容易恢复的数据条带与非常慢或无法读取的数据交替出现。[据我所知，这似乎表明磁头与盘片接触，损坏了表面并释放了磁性灰尘，然后这些灰尘随着离心力扩散开来。而且由于伺服轨道（其中包含启动过程的基本信息）位于硬盘驱动器（3.5 英寸日立 1 TB）的外缘，一些灰尘可能已经到达它，使其难以接近，这可以解释启动时频繁发出咔嗒声的原因。]（如果我错了请纠正我。）=> [EDIT 20200501] 这是错误的，实际上这种模式通常表示驱动器的一个磁头已完全发生故障并且不再读取任何内容，此时盘片上的数据可能仍然可以读取，但需要更换磁头组件，而这只有专门的数据恢复实验室才能安全地执行。
以下是ddrescueview第二次恢复的地图：
因此硬盘变得非常不稳定，在 165 GB 左右之后恢复变得越来越困难，但在此之前复制速度一直很高，没有跳过任何区域。后来我使用了该ddru_ntfsbitmap方法进行最后的尝试，因此未分配的空间大部分都被跳过了。
这是ddrescueview用创建的日志文件的地图ddru_ntfsbitmap，其中显示硬盘驱动器中包含实际数据的区域（绿色）和可用空间（灰色）：
幸运的是，大部分实际数据位于第一季度，并已成功恢复。现在我还没有将这两个映像的好部分合并起来，并提取实际文件，可能使用 R-Studio（我尝试过的最好的数据恢复软件）。
关于我最初的问题，我后来发现了一件有趣而又奇怪的事情（我想我应该按照正式规则把它作为评论，但它太长了，我无法提供截图）。
我尝试将 Ext4 分区上映像 2 的已挽救区域（映像 1 中缺少该区域）复制到 NTFS 分区{1}上的映像 1中，这应该以非常高的速率完成（输入和输出都在健康的 2 TB 硬盘上），但我得到的平均速度只有 660 KB/s，因此非常接近后期初始恢复的速度，当时我非常担心并首先提出这个问题......
使用的命令（图像 2 的日志文件用作域日志文件）：
ddrescue -m [image2.log] [image2] [image1] [image1.log]
截屏：
于是我停下来，做了相反的事情：我将映像 1（NTFS）中映像 2（Ext4）中缺失的挽救区域复制到映像 2 中 — 现在复制速度平均约为 43000 KB/s 或 43 MB/s（可能比在同一硬盘上复制的预期速度稍慢，因为 Seagate 2 TB 的最大写入速度接近 200 MB/s，因此从一个分区复制到另一个分区应该能够达到 100 MB/s 左右，但仍然比第一次尝试好 100 倍）。如何解释如此巨大的差异？
使用的命令（图像 1 的日志文件用作域日志文件）：
ddrescue -m [image1.log] [image1] [image2] [image2.log]
截屏：
我注意到，两个分区上的映像文件的“磁盘大小” {2}对应于实际写入的数据量，与总大小（1 TB 或 931.5 GB）相差甚远，尽管我没有使用开关-S（“对输出文件使用稀疏写入”）。映像 2（使用映像 1 中的额外救援区域完成之后）的“磁盘大小”为 308.5 GB，而映像 1 的“磁盘大小”为 259.8 GB。如果 Linux NTFS 驱动程序在处理稀疏写入时遇到麻烦，这是否与复制速度慢有关？考虑到我没有使用该-S开关，为什么在写入最后的扇区后没有立即分配整个大小？
我尝试-p在过程一开始就使用开关（“预分配”），认为这样会“更干净”、更直接、更容易处理，以防万一出现问题（如果恢复需要恢复……），但我不得不停下来，因为它太长了，我想尽快开始（显然它实际上会写入空数据而不是简单地分配所需的扇区）。然后我发现通过-R暂时使用开关（“反向”），它会将最后的扇区写入输出文件，从而按照我的意图分配完整大小；它确实导致输出文件的大小增加到 931.5 GB，但“磁盘上的大小”实际上要小得多（我后来在 Windows 上访问用于该恢复的 HDD 并看到异常高的可用空间时注意到了这一点）。________________
{1}
我仍然不明白第二次恢复尝试如何能对前 100 GB 左右产生更好的结果，尽管在此期间 HDD 的健康状况已经下降。 [EDIT 20200501] => 这可能是因为a500000最初使用的参数跳过了读取速度低于 500KB/s 阈值的区域。如果没有该选项，第二次读取时，它会立即读取较慢的区域。事实上，那些较慢的区域与磁头较弱有关，因此，尽管这个故障磁头已经出现故障迹象，但第二次读取时仍能获取同样多的数据，这仍然令人费解。我还在学习……
{2} 顺便说一句，Windows 和 Linux 系统上的“磁盘”一词都应该被替换，因为有些数据存储单元不是“磁盘”......
答案2
您可能需要先使用以下命令复制磁盘映像日命令
sudo dd bs=[block_size] count=[NofBlocks] if=[in_file] of=[out_file]
在哪里
[in_file]-可能是损坏的磁盘，例如 /dev/sdd2
[out_file]-输出图像文件的位置。
- 装载图像并尝试恢复它。