标签: ddrescue

假设您想将故障硬盘归零。您想尽可能多地用零覆盖。您不想要的是：进程在第一个写入错误时中止。怎么做？

AFAICS，plaindd仅提供忽略读取错误的选项。因此，像

dd if=/dev/zero of=/dev/disk/by-id/lousy-vendor-123 bs=128k

是不足够的。

ddrescue 似乎更擅长忽略错误 - 但它的最佳命令行是什么？

我对 GNU ddrescue 的尝试：

ddrescue --verbose --force --no-split /dev/zero /dev/disk/by-id/lousy-vendor-123

我正在从 1 TB 故障驱动器中抢救数据（在更换硬盘的过程中询问过它？）。我ddrescue从系统救援 USB 中完成了 557568 B 在 191 个错误中产生的错误大小，可能全部在/home（我假设它所谓的“错误”不是坏扇区，而是它们的连续序列）。

现在，我看到的几个指南建议e2fsck在新磁盘上做，我希望这会以某种方式发现某些文件已被分配“空白扇区/块”，至少知道哪些文件无法保存所有的。但是根本没有发现任何错误（我运行它但没有-y确保我没有遗漏任何东西）。现在我用 再次运行它-c，但到目前为止 95% 没有发现错误；我想我有一个新驱动器，里面有一些看起来正常的文件，里面有归零或随机的部分，直到我用相应的软件打开它们或 Linux Mint 需要它们时才能检测到它们。

我可以对旧/新驱动器做任何事情以获得可能损坏的文件的列表吗？我不知道它们有多少，因为那 191 个可以跨文件，但至少总大小并不大；我最关心的是一大堆旧的家庭照片和视频（每个 1+ MB），其余的可能无关紧要或最近已备份。

更新：e2fsck 的新通行证确实提供了一些新的东西，我对此一无所知：

Block bitmap differences:  +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).                    
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes

1. 磁力驱动器出现故障。
2. 我使用 ddrescue 使用地图文件恢复了大约 85% 的数据，但其余部分已被破坏，继续清理它需要数年时间。
3. 我可以退货换货。
4. 我想先粉碎我的数据。
5. 当我尝试写入它时，它适用于前几百 MB，但随后开始出现输入/输出错误并且驱动器变得完全不可用（/dev/sdd 不再存在）。

那么是否可以使用第 2 项中的映射文件将随机数据仅写入驱动器的可恢复部分而不尝试写入坏块？

在尝试从发生故障的硬盘驱动器恢复数据的过程中，我正在运行该命令ddrescue。

该命令已经运行了 9 天，我从磁盘活动的声音中认为它可能正在执行某些操作。命令行输出一直看起来或多或少是静态的：

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

一直在变化的一个部分是它说ipos和的地方opos。花了 9 天时间才恢复到大约500000 MB，这是发生故障的磁盘驱动器的大小。然而，当它到达那里时，它又下降到0并开始再次上升。在我写这篇文章的时候，它大约在2580 MB …

我正在尝试使用 ddrescue 从 SDHC 卡中抢救数据：

while true ; do ddrescue -d /dev/mmcblk0p1 mmc.img mmc.log ; done

控制器，我不确定它是卡上的还是我笔记本电脑中的，在读取了一定数量的坏扇区后，似乎会返回所有扇区的错误（显示在系统日志中） t 显示在 syslog 中），我发现将卡再次弹出并插入插槽会重置它并再次将好扇区报告为好，直到读取了太多坏扇区，依此类推。

目前我正在使用这个循环，密切关注 ddrescue 的状态输出，手动重置卡。有没有办法在不取出卡的情况下重置控制器，以便救援过程可以无人看管？

也许这是相关的，但在这台戴尔笔记本电脑中，为了让读者注意到插入了卡，它必须在启动或使用期间完成echo 1 > /sys/bus/pci/rescan，但只有一次，之后读卡器 PCI 设备出现，一切都按预期工作：

07:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30)
        Subsystem: Dell Device 046e
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f0600000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [a4] Power Management version 3
        Capabilities: [80] Express Endpoint, MSI 00
        Capabilities: [94] MSI: Enable- Count=1/1 …

我正在从我的笔记本电脑中恢复硬盘驱动器（根本无法启动，磁盘工具报告说没有问题，但不会安装磁盘）。我已经通过 USB 适配器连接了 HDD。ddrescue像这样运行：

sudo ddrescue -v -n /dev/disk1s2 "/Volumes/Original HD/image.dmg" ddrescue.log

到目前为止没有错误，但平均读取速度已经逐渐下降到 50KB/s。开始时大约是 2MB/s。分区大小为 300GB。到目前为止，我已经能够恢复 160GB。我正在恢复到 MacBook 上的 HFS+ 分区。

这种传输速率缓慢的原因可能是什么以及如何提高它？

背景/背景：

我目前正在运行 GNU ddrescue 1.18.1 以从 USB 恢复数据，该 USB 在我将虚拟磁盘映像写入 disk2s1 分区时遇到电缆断开连接。最初我正在恢复我的第二个分区 (disk2s2) 并注意到我已经进入了第三阶段（拆分）。我将图像放置到网络存储上。

题：

我注意到这个阶段是循环的。鉴于我当前的状态信息（我只显示两个错误），有没有办法计算我可能遇到的循环次数？

地位：

更新/编辑：

所以我仍然对如何使用 ddrescue 工具估计完成的循环/时间非常感兴趣。根据评论，我正在添加对当前正在运行的 disk2s1 分区的日志文件的评估（disk2s2 在 14.5 小时后完成，一个用户中断了大约 6 小时）。

完成的分区日志

对于刚刚完成的分区，这里是日志检查的结果。

参考（ddrescue 算法笔记）：

4 算法

GNU ddrescue 不是 dd 的衍生物，也与 dd 没有任何关系，只是两者都可以用于将数据从一个设备复制到另一个设备。主要区别在于 ddrescue 使用复杂的算法从故障驱动器复制数据，尽可能减少对它们造成的额外损害。

Ddrescue 有效地管理正在进行的救援状态，并尝试首先救援好的部分，然后安排在坏（或慢）区域内读取。这最大限度地增加了最终可以从故障驱动器中恢复的数据量。

标准 dd 实用程序可用于保存故障驱动器中的数据，但它会按顺序读取数据，如果错误位于驱动器的开头，这可能会磨损驱动器而无法挽救任何东西。

其他程序按顺序读取数据，但在发现错误时切换到小尺寸读取。这是一个坏主意，因为这意味着在错误区域花费更多时间，损坏表面、磁头和驱动器机械装置，而不是尽快摆脱它们。这种行为降低了挽救剩余良好数据的机会。

ddrescue 的算法如下（用户可以随时中断进程，但要注意坏的驱动器会阻塞 ddrescue 很长时间，直到内核放弃）：

1) 可选择读取描述多部分或先前中断救援状态的日志文件。如果未指定日志文件或为空或不存在，则将所有救援域标记为未尝试。

2）（第一阶段；复制）读取输入文件的未尝试部分，将失败的块标记为未修剪并跳过它们。也跳过慢速区域。跳过的区域稍后会在两次额外的通道中尝试（在修剪之前），在每次通过后反转方向，直到尝试所有救援域。第三遍是扫遍，禁用跳过。（目的是快速界定大错误，保持日志文件小，并为修剪产生良好的起点）。在大块中仅读取未尝试的区域。修剪、拆分和重试是逐个扇区完成的。每个扇区最多尝试两次；此步骤中的第一个（通常作为大块读取的一部分，但有时作为单个扇区读取），以下步骤之一中的第二个作为单个扇区读取。

3）（第二阶段；修整）从最小的未修整块的前沿开始，一次读取一个扇区，直到发现坏扇区。然后从同一块的后沿开始向后读取一个扇区，直到找到坏扇区。对于每个未修剪的块，将找到的坏扇区标记为坏扇区，并将该块的其余部分标记为未拆分，而无需尝试读取它。重复直到没有更多未修剪的块。（较大的未修剪块是由较小块的串联产生的，因此它在边缘的良好数据的比例较小）。

4）（第三阶段；拆分）读取从最大的非拆分块的中心一次向前一个扇区，直到找到坏扇区。然后，如果找到的坏扇区不是第一个尝试的，则从同一块的中心一次向后读取一个扇区，直到找到坏扇区。如果日志文件大于“--logfile-size”，则顺序读取最大的非拆分块，直到日志文件中的条目数低于“--logfile-size”。重复直到所有剩余的非拆分块都少于 7 个扇区。然后依次读取剩余的非拆分块。

5）（第四阶段；重试）可选地尝试再次读取坏扇区，直到达到指定的重试次数。每个坏扇区在每次传递中只尝试一次。Ddrescue 无法知道坏扇区是否不可恢复，或者在重试后是否最终会被读取。

6) 可选择写一个日志文件供以后使用。

总错误大小 ('errsize') 是所有未修剪、未拆分和坏扇区块的大小之和。它在复制阶段增加，在修剪、拆分和重试期间可能减少。请注意，随着 ddrescue 拆分失败的块，使它们更小，总错误大小可能会减少，而错误数量会增加。

日志文件会定期保存到磁盘，以及在 ddrescue 完成或中断时保存。因此，如果发生崩溃，您只需重新复制即可恢复救援。保存间隔从 30 秒到 5 分钟不等，具体取决于日志文件的大小（更大的日志文件以更长的间隔保存）。

此外，同一个日志文件可用于复制输入文件不同区域的多个命令，以及对不同子集的多次恢复尝试。看这个例子：

首先拯救光盘最重要的部分。ddrescue -i0 -s50MiB …

我有两个通过相同媒体的连续恢复尝试创建的 ddrescue 映像。两幅图像大小相同但数据互补：

$ od part-one/ddrescue_image --skip-bytes 227966006774 --read-bytes 32
3242365232766 113056 016517 102014 074371 144073 000000 000000 000000
3242365233006 000000 000000 000000 000000 000000 000000 000000 000000
3242365233026
$ od part-two/ddrescue_image --skip-bytes 227966006774 --read-bytes 32
3242365232766 000000 000000 000000 000000 000000 124616 163450 064251
3242365233006 074567 134433 012742 022160 044301 054235 140604 020633
3242365233026

如何将它们合并成一个完整的图像？

细节

• 第二张图片只是第一次恢复尝试的延续，à la：

  $ ddrescue corrupt-partition part-one/ddrescue_image part-one/ddrescue_log
  $ mkdir part-two; cp part-one/ddrescue_log part-two/ddrescue_log
  $ ddrescue corrupt-partition part-two/ddrescue_image part-two/ddrescue_log
  

  Run Code Online (Sandbox Code Playgroud)

• 第二个图像几乎完全为零，但包含分布在 1847 个孤立区域的 18 KB …

我很难找到其他有同样错误的人，我正在努力找出前进的最佳途径。

我有一个速度慢得无法使用的硬盘，然后停止启动。clonezilla 克隆失败了，我开始了 ddrescue，使用包含在 clonezilla live cd 中的 gnu 救援工具。对于一个 2 TB 的驱动器，平均大约 400 kBps 的速度慢得令人难以置信，所以我估计将近 4 个月！这一点。遗憾的是，我上次备份是在大约 2 年前，我想从中删除很多照片。令人惊讶的部分是它拯救了大约 50 GB，到目前为止没有错误，即使它花了 3 天。我对前进的最佳路径有几个问题，以及为什么要花这么长时间但也没有任何错误。

驱动器是否需要很长时间才能成功读取，但从未真正失败，从而减慢了复制时间？硬盘本身没问题，但控制板之类的问题？

我非常担心日志文件可能会去哪里。我不能指望我的电脑保持稳定，而且命令四个月都没有出错。如果我说的是让它连续运行数周，我想将该日志文件放到闪存驱动器上。我最初认为它会转移到新的更大的硬盘驱动器上，但现在我意识到它可能会出现在 clonezilla_live 正在使用的 RAM 驱动器上。插入格式化的 USB 驱动器、安装它并复制日志文件，然后重新启动 ddrescue 是否安全？clonezilla shell 甚至会识别出我插入了启动时不存在的 USB 记忆棒，以便我可以安装它吗？

我假设我会尝试sudo fdisk -l列出磁盘，然后创建一个目录？sudo mkdir /logfile/usb然后挂载呢？sudo mount /dev/sdb1 /media/usb，然后复制？

对于任何反馈，我们都表示感谢。我在 Unix shell 中搞砸了一点，设置了 z-pool raid，但总是当我确切地知道我在做什么时，而不是在 linux 中，更不用说准系统版本了。

我正在学习拥有良好备份的价值。

我有一个 500GB 的硬盘驱动器出现故障。我开始跑步

ddrescue /dev/sdb1 backup.img mapfile

这将需要 40 到 70 天，这取决于你看它的那一刻。

我阅读了这篇文章，其中展示了如何ddrescue使用-c 1Ki选项加快速度。现在我在看 15 天左右。

我还缺少另一个技巧吗？或者更好的工具？这真的是恢复故障硬盘所需要的吗？