我在 Lubuntu 实时系统上使用 ddrescue 对一个可能存在缺陷的 1TB 硬盘驱动器进行了映像处理，该驱动器包含大约 270GB 的实际数据。恢复已完成 99.9%，只有 300MB 标记附近有 52KB 的区域无法读取 - 但 SMART 中没有“待处理”或“重新分配”的扇区。第一个问题：这怎么可能？这可能是“逻辑”坏扇区的良性情况吗？即扇区在物理上仍然可以运行，但处于不一致的状态，导致 CRC 校验失败，是否可以通过覆盖它们来持久可靠地“修复”它们？我运行了简短的自检，结果为“读取失败”。我仍然可以 100% 信任 SMART 数据，并确信如果它报告没有坏扇区，那么物理层面上确实没有坏扇区？
然后，我有 3 个备用驱动器，我可以用它们将恢复的数据传送给使用 MacBook 电脑的所有者：USB2 上的 320GB 驱动器、USB3 上的 500GB 驱动器、USB3 上的 1TB 驱动器。源驱动器格式化为 HFS+。有没有一种安全方便的方法可以将这个 1TB 映像（实际上只占用大约 270GB）直接写入较小容量的驱动器（因为它是使用 ddrescue 的 -S 开关在稀疏模式下创建的），使用 Linux 或 Windows 免费工具，这样恢复的 HDD 就易于读取，具有一致的分区表？（我没有使用 Apple 分区和格式化方案的经验。）或者我最好创建一个 HFS+ 分区（使用哪种工具，因为 GParter 显然无法处理这个）并复制文件和文件夹？但在这种情况下，时间戳和其他元数据会自动保留吗？还是我必须使用特定的方法来确保这一点？像“cp”这样的 Linux 命令可以在 HFS+ 分区之间复制文件并保留该文件系统特有的所有属性吗？
谢谢。
答案1
所以我按照直觉做了：我尝试用这个 ddrescue 命令覆盖那个微小的不可读区域（可以用更基本的 dd 工具来完成，但我不太熟悉它）：
lubuntu@lubuntu:~$ sudo ddrescue -o 312881152 -s 53248 -f /dev/zero /dev/sdb /media/lubuntu/354E48E260FCFD84/dev_zero_dev_sdb.log
[Note : the -f switch is necessary here since there is natively a protection preventing ddrescue from writing directly to a physical device.]
并且它起作用了：作为验证，我重新映像了第一个 GB，这次没有错误（我在运行上述命令之前尝试过这种部分映像，当时错误区域仍然存在，具有完全相同的位置和大小，我还注意到它立即被跳过，没有任何减速，这与通常发生的情况相反，当存在实际的“物理”坏扇区时，它会减慢速度或挂起几秒钟后再跳过）；“简短自检”现在也已完成，没有错误。
在此之前，我尝试了一些 Windows 工具：使用 Hard Disk Sentinel 进行读取扫描使其无限期冻结，我不得不关闭驱动器；同样，尝试使用 WinHex 访问有问题的区域使其冻结，直到驱动器被关闭。
那么，我是否正确地认为这是一个“逻辑”坏扇区的情况，并且该驱动器在物理上是完好的，并且可以再次安全使用，因为在整个过程中 SMART 中从未显示过“待处理”或“重新分配”的扇区？ 造成这种情况的可能原因是什么，也许是由于不正确的关机而中断了写入操作？ 这是一个常见问题吗？当它影响系统文件时，它是否通常会导致驱动器无法运行？