磁盘读取某片受损区域时迟迟没有进展，就会带来一个调度问题：其他地方还有可读的数据，恢复程序该在这里耗费多少时间？GNU ddrescue 的做法是先保存容易读出的数据，再用一份映射文件记下尚未完成的工作。在这种设计下，一次恢复尝试可以接续、可以改变方向，也可以逐步积累有用的结果。[1]

体积庞大的磁盘镜像旁，那份小小的文本文件正是这套设计的核心。镜像保存截至当前恢复出的字节，mapfile（映射文件）则指明下一轮运行还有哪些工作要做。两者一起保留，停下来的含义也随之改变：一次中断，可以为下一次尝试留下有用的起点。[1]

映射文件记住未完成的工作

mapfile 用起始位置、长度和状态描述各段数据范围。它以不同符号区分尚未尝试读取的范围（?）、等待修整的读取失败块（*）、等待刮取的块（/）、坏扇区（-）和已成功复制的范围（+）。另有一行状态记录，保存当前位置、操作和轮次。[2]

这些区分很有用，因为一次大块读取失败，只能说明这次读取受阻，块内各个扇区是否可读仍有待确认。算法可以回来，以更小的单位重新读取。若将整片区域判为永久丢失，就会放弃后续恢复的机会；若将它视为全未尝试过的区域，已有的读取经验又会丢失。映射文件保留了这份中间状态。[2]

项目还附带 ddrescuelog，用于检查、比较和操作 mapfile。除了运行中的进度显示，操作者和其他工具也能直接读取恢复状态。[1]

跳过一片区域，也能推进恢复

1.30 版手册将恢复分为五个阶段：复制（copying）、修整（trimming）、扫掠（sweeping）、刮取（scraping）和重试（retrying）。复制阶段寻找有望读出的未读区域；修整阶段从紧邻已成功读取区域的边缘向读取失败块内部推进。扫掠阶段读取那些在出错后被跳过、仍待处理的区域。刮取阶段逐扇区处理尚未解决的部分；可选的重试轮次则再次尝试读取坏扇区。[2]

这样的次序，安排的是恢复工作该把力气花在哪里。未读区域仍作为待办事项留在映射文件中，程序则有机会先保存其他位置的可读数据。因此，遇到错误后先继续向前，同样能带来进展，出错区域可以留待后续处理。

2026 年 1 月 4 日发布的 1.30 版进一步明确了这一取舍。Antonio Diaz Diaz 将原先的第五轮复制替换为修整之后的扫掠阶段。这个版本还将第二轮复制和修整限制在已恢复数据旁的相关边界。发布说明提出，这些调整旨在改善程序对磁头失效硬盘的自动处理。[3]

一项小小的命令选项变化，足以影响旧笔记的用法：-N 现在表示 --no-sweep，此前表示 --no-trim。同一条记忆中的命令，在 1.30 版下会表达不同的恢复策略。发布公告有助于厘清这些行为变化，其中具体恢复案例的结果仅限于该案例本身，对其他受损硬盘的恢复效果没有保证。[3]

镜像需要与映射文件一起保留

默认情况下，ddrescue 保留已有输出文件的内容，输入中无法读取的区域也不会以零值覆盖到输出中。后续运行可以继续填补缺口，同时保留此前成功恢复的数据。[1] 因此，如果目标文件原先就存在，其中与未读区域对应的位置仍可留有目标文件的旧字节。要区分这些位置与成功恢复的数据，需要查看 mapfile。[2]

设想一下交接时只收到镜像的人所面对的情况。文件即使能打开、文件系统即使能挂载，某些数据范围的状态仍有待确认。在把输出中的每个字节都视为源介质上的数据证据之前，可以先借助映射文件查看哪些位置采集成功。镜像和映射文件一起保留，接手的人也就有据可查。

TestDisk 文档明确说明了接下来的分工：先制作副本，再在克隆副本上开展恢复工作。将受损扇区复制到健康的存储介质上，无法重建其中缺失的内容。恢复出的文件若依赖这些缺失字节，仍有损坏的风险。[4]

容量也属于这套设计需要考虑的内容。在 TestDisk 的示例中，保存一份 1 TB 磁盘镜像，文件系统至少需要 1 TB 可用空间。如果直接从磁盘复制到另一块磁盘，目标盘的实际容量至少要与源盘相等，而标称容量相同的磁盘，实际大小也会有差别。[4] 要让输出结果成为可浏览的文件集合，首先得为它准备足够的存储空间。

数据采集只是保存工作的一步

泰特美术馆（Tate）关于保存软件艺术的记录，展示了这件专用工具的位置。团队用 Guymager 完成常规镜像制作，用 ddrescue 和 dvdisaster 处理受损介质。整套设备与流程还包括写保护器、适配的驱动器连接，以及单独的镜像制作报告，记录源设备、所用工具、目标格式和质量检查。[5]

这份独立的艺术品保护记录，让 ddrescue 的作用有了具体尺度：它是一套能力出色的数据救援引擎，在有组织的数据采集流程中发挥作用。识别艺术作品依赖哪些组件、判断恢复出的软件是否仍按预期运行，都超出了它的职责。泰特将仿真视为后续阶段，为它另写报告，并在条件允许时对照原始硬件检查。[5]

密歇根大学图书馆在处理 Robert Altman 的数字介质时，也记录了类似的背景资料需求。工作人员为软盘拍照、抄录标签、制作镜像、检查能否访问其中的内容，再将镜像连同元数据和报告一起打包。校验和用于追踪文件在处理和传输期间是否发生变化。[6]

对小型档案机构或技术团队来说，这个实例提示了一种易于落实的交接做法：将源介质标识、镜像、mapfile、工具版本和采集笔记保存在一起。这一建议是从上述流程记录推导而来，不能据此认定 ddrescue 会生成完整的归档包。恢复出了哪些内容，仍需有人检查；哪些内容尚未恢复，也仍需留下记录。[1][5][6]

终端上的百分比之外，有用的恢复成果还包括可读的数据，以及足以让工作继续的依据。GNU ddrescue 让下一次读取的决定，建立在上一次尝试留下的记录之上。

资料来源

1. GNU 项目，《Ddrescue — Data recovery tool》——项目概览、可接续的复制、输出行为和 ddrescuelog。
2. Antonio Diaz Diaz，《GNU ddrescue 手册》，1.30 版（2026 年 1 月 1 日）——算法、mapfile 格式，以及输出中未恢复区域的含义。
3. Antonio Diaz Diaz，《GNU ddrescue 1.30 released》（2026 年 1 月 4 日）——扫掠阶段、读取边界调整，以及 -N 选项的新含义。
4. Christophe Grenier，TestDisk 文档，《DDRescue: data recovery from damaged disk》——在克隆副本上操作、缺失数据与目标容量。
5. Tom Ensom 与 Patricia Falcão，《Preserving Software-Based Art at Tate: From Research to Best Practices》，Electronic Media Review 第 7 卷——关于镜像工具、采集记录和仿真的独立保护实践记录。
6. Leigh Anne Gialanella，《Disk Imaging for Preservation: Part 1》，密歇根大学图书馆（2018 年 1 月 19 日）——Robert Altman 数字介质的处理流程、背景记录与校验和。
7. Alchemist-hp，《Hard disk head crash》（2009 年 9 月 12 日），Wikimedia Commons——原始照片与署名信息。