标签: ddrescue

我正在尝试从朋友的故障外部 USB 驱动器中抢救数据。驱动的问题是无法读取，windows下不行，linux下也不行。但是我确实设法在驱动器上运行 ddrescue 并构建驱动器的映像以供以后处理。

但是，我是今年一月份开始的进程，一直在不停地运行，还在运行。所以现在5个多月了。起初它以大约 2000 b/s 的速度运行，现在它回落到 200 b/s。它拯救了大约 27GB 的数据（驱动器是 2TB），据朋友说，这也或多或少是存储在驱动器上的数据量。获救的规模仍在增加，但 veeeeeeeeeery 缓慢。例如，在过去 3 周内，它增加了 200mb。

有什么办法可以停止这个过程并继续到现在为止已经救出的东西，还是 ddrescue 真的必须完成整个过程才能使用 img 文件？

今天ddrescue停止了，因为驱动器丢失了。下面是我在屏幕上看到的图片，正在运行 ddrescue 日志查看器，不确定它是否可以了解情况。我重新启动了 ddrescue，它再次以与以前相同的慢速运行。

因此，在从旧笔记本电脑到新笔记本电脑的途中，旧笔记本电脑的硬盘受到了一些物理损坏。badblocks报告 64 个坏道。我有一个两个月大的 Ubuntu GNOME 设置，带有拆分/和/home分区。据我所知，其中的一些扇区/已损坏，但这不是问题。另一方面，/home的分区给了我这个带注释的 ddrescue 日志：

# Rescue Logfile. Created by GNU ddrescue version 1.17
# Command line: ddrescue -d -r -1 /dev/sdb2 home.img home.log
# current_pos  current_status
0x6788008400     -
#      pos        size  status
0x00000000  0x6788000000  +
0x6788000000  0x0000A000  -
    first 10 sectors of the ext4 journal
0x678800A000  0x2378016000  +
0x8B00020000  0x00001000  -
    inode table entries for /pietro (my $HOME) and a few folders within
0x8B00021000  0x00006000  + …

不久前，我在一个垂死的 HDD 上进行了 2 次救援尝试；我首先运行（GNU）ddrescue，然后直接dd进行手动搜索。我想充分利用这两个图像。由于文件中的任何空段都只是 0，因此按位与应该足以合并两个文件。

是否有一个实用程序允许我创建一个文件，该文件是两个输入文件的 OR？

（我正在使用 ArchLinux，但如果它不在存储库中，我很乐意从源代码安装）

这个问题解决了第一遍的ddrescue在被救出的设备。

我不得不抢救一个 1.5TB 的硬盘。

我使用的命令是：

# ddrescue /dev/sdc1 my-part-img my-part-map

当在磁盘的一个好的区域上启动救援（没有可选参数）时，读取速率（“ current rate”）保持在 18 MB/s 左右。

它偶尔会变慢一点，但后来又恢复到这个速度。

但是，当它遇到磁盘坏区时，它可能会明显变慢，然后再也不会回到 18 MB/s，而是保持在 3 MB/s 左右，即使读取 50 GB 的好磁盘也没有问题.

奇怪的是，当它当前正在以 3 MB/s 的速度扫描一个好的磁盘区域时，如果我停止ddrescue并重新启动它，它会以 18 MB/s 的更高读取速率重新启动。ddrescue 当它以 3 MB/s 的速度运行时，我通过停止和重新启动实际上节省了大约 2 天，我必须这样做 8 次才能完成第一遍。

我的问题是：为什么它ddrescue不会自己尝试回到最高速度。考虑到文档中明确规定的首先快速完成简单领域的政策，这就是应该做的事情，而我观察到的行为在我看来似乎是一个错误。

我一直想知道这是否可以处理的选项 -a或--min-read-rate=… 但手动如此简洁的，我不知道。此外，我不明白应该根据什么为该选项选择读取率。应该是18MB/s以上？

尽管如此，即使有一个选项来指定它，我很惊讶默认情况下没有这样做。

元笔记

两名用户投票结束了主要基于意见的问题。

我很感激知道它是什么意思？

我在一个实际示例中以一定的数值​​精度描述了一个重要软件的行为，清楚地表明它不符合其文档中规定的主要设计目标（尽快完成简单的部分），并且非常简单的推理可以改善这一点。

该软件是众所周知的，来自一个非常值得信赖的来源，具有精确的算法，我希望大多数缺陷早就被淘汰了。因此，我向专家询问这种意外行为的可能已知原因，而不是我自己在这个问题上的专家。

此外，我问是否应该使用软件的选项之一来解决问题，这是一个更精确的问题。我要求详细的方面（如何选择此选项的参数），因为我没有找到相关文档。

我问的是我工作所需的事实，而不是意见。我用实验事实而不是意见来激励它。

我有一个 500GB 的外置硬盘，我需要拯救其中的内容。不幸的是，我只有两个 400GB 的分区来保存内容。我可以将磁盘映像拆分为：

~$ cd /mnt/part1/Recovery/
/mnt/part1/Recovery/$ ddrescue -f -n -i0 -s250...00 /dev/disk disk.part1.ddraw disk.part1.log
/mnt/part1/Recovery/$ cd /mnt/part2/Recovery/
/mnt/part2/Recovery/$ ddrescue -f -n -i250...00 /dev/disk disk.part2.ddraw disk.part2.log

（为方便起见，数字值缺少几个零）。也就是说，我可以使用-i和-s标志手动将磁盘映像分成两部分吗？

其次，有没有办法可以将图像的两个部分安装为一个？

在将损坏的文件系统映像到另一个硬盘驱动器上的文件之前，我决定试运行ddrescue（将救援的输出扔到/dev/null）只是为了看看有多少数据不可读：

# ddrescue -d -b 4096 -r 3 -f /dev/sda1 /dev/null sda1.log

最终花了3天的时间才完成。现在我已经准备好制作真实的图像，但我不想再等三天才能完成。但是，幸运的是，因为我有一个日志文件，是否可以强制ddrescue仅救援好扇区而不触及坏扇区？

阅读了一些文档后，我提出了以下想法：

# ddrescue -d -b 4096 --fill=+ /dev/sda1 /mnt/sda1.img sda1.log

这行得通吗？是否有另一种（首选）方法仅重读好扇区？

我的 ext4 磁盘崩溃了，我正在使用 ddrescue 尝试挽救它。然而，崩溃的磁盘是 3tb，我只有另一个 3tb 驱动器用于图像文件。我认为这个图像文件对于全新的空磁盘来说太大了，所以在救出 2700GB 后，我中断了这个过程，试图将图像的其余部分写入第二个磁盘。

我开始了这个过程

ddrescue -v --no-split /dev/sdc /mnt/red/imagefile /mnt/500gb/logfile

/dev/sdc 是崩溃的磁盘 /mnt/red 是新硬盘，imagefile 是我的图像 /mnt/500gb/logfile 是日志文件

一切看起来都很正常，直到我中断了映像，所以我尝试使用以下命令在第二个磁盘上继续映像：

ddrescue -v --no-split /dev/sdc /mnt/500gb/imagefile2 /mnt/500gb/logfile

即，与之前完全相同的命令，只是将图像文件定向到另一个磁盘

但是，几秒钟后 ddrescue 退出并抱怨设备上没有剩余空间，但设备除了日志文件外是空的。我不明白的是，imagefile2 是立即创建的，大小为 2,732,050,104,320（假设字节），与第一个图像文件中拯救的大小大致相同。

我在任何地方都找不到任何关于为什么会这样的说明。我假设第二个图像文件的大小与要拯救的剩余数量大致相同。即 250GB。

我首先运行以下命令，开始对 AF/512e HDD 进行成像：

    ddrescue -n /dev/sdb2 drive_c.img mapfile.log

完成后，我对 mapfile.log 进行了备份，并决定使用驱动器的 4K 物理扇区大小通过直接磁盘访问来运行拆分阶段：

    ddrescue -d -b4096 -r3 /dev/sdb2 drive_c.img mapfile.log

如果我选择了 512 字节的扇区大小，我会从坏扇区中刮取更多吗？

在我写这篇文章的时候，分裂阶段已经完成，坏扇区正在第二次重试。当然，mapfile 中几乎所有的坏块都是 n×4K 大小的。如果我运行相同的命令但使用 512 b 扇区，我是否能够从它们中刮取更多？

思绪与困惑

首先，我什至不确定使用直接磁盘访问是否合适。

ddrescue 的信息文件调用直接磁盘访问开关时

日志文件中的位置和大小始终是扇区大小的倍数

这意味着

内核正在缓存磁盘访问并将它们分组。

因此，如果我的内核对请求进行了“分组”，则映射文件中的最小块应该是 8K 或 16K。然而，就我而言，mapfile 包含大量 512 字节的块，这些块在第一次运行完成后既不可读又被抢救。

在第二次运行期间，512 b 块中的大部分合并为 4K 块。例如，在分裂阶段之前与非分裂块相邻的 512 b 坏扇区与相邻的坏扇区合并在一起。这对我来说似乎很好。可能，在修整阶段，硬盘驱动器上的磁头无法读取 4K 扇区，因此它返回 512 b 坏扇区给 ddrescue。修整在那里结束，512 b 扇区后面的块被标记为非分割。

看起来不正常的是有一个 512 b 坏扇区，如下图所示：

为什么磁头能够读取 4K 扇区，但声明其中只有 1/8 不可读？我的印象是物理扇区是由磁头原子读取的？因此，如果它的一部分不好，那么整个部门都是坏的。

这显然提出了一个问题——是否可以通过运行 ddrescue 直接访问或不直接访问但具有 512 b 扇区大小来从 4K“部分坏”扇区获取数据？

显然有些事情不会加起来。

顺便说一句，这是我第一次发布问题，所以如果格式与论坛不一致或问题过多，请原谅。但除此之外，我将很高兴获得与主要问题相关的任何主题的输入，即高级格式、直接磁盘访问、内核缓存等。来自读者。

干杯!

我目前正在尝试使用 ddrescue 从出现故障的 3TB WD Red 驱动器中恢复数据。

两周后，我得到了大约 1 TB，但随后读取速度增加到每秒几千字节，现在需要数年时间才能完成。我注意到，关闭和打开驱动器电源会在几秒钟内将读取速度提高到每秒几百/千字节，然后再次下降到超慢。

我猜想盘片上有一些灰尘粘在磁盘头上，当磁头滑到停车位置时会被清除。
ddrecsue 当前运行如下：

ddrescue -f -n -b 4096 /dev/sda /dev/sdb /media/usbstick/rescue.log

我现在想跳过这个区域并继续其他地方，比如说 1500GB，但不知道该怎么做。有参数--input-position=bytes，但文档说：

infile 中救援域的起始位置（以字节为单位）。默认为 0。这不是 ddrescue 开始复制的点。

还有，--skip-size=[initial][,max]但似乎是在坏扇区后跳过的大小，这不是我想要的。

有什么想法如何实现这一目标？

我正在ddrescue从磁盘 A运行到磁盘 B。

我原以为较慢的磁盘会一直全速运行，而另一个磁盘的运行速度足以跟上。

想象一下当vmstat 5（即下面的数字是 5 秒平均值）给出这个输出时我的惊讶：

procs -----------memory----------    ---swap-- -----io----      -system--    -----cpu-----
 r b  swpd   free   buff     cache   si so     bi     bo        in   cs      us sy id wa st
 2 0  608260 234672 21308688 4346420 0  0      116890 31        1374 2884    1  4  85 10 0
 0 1  608260 232820 21309700 4348712 0  0      134248 53        1546 3354    1  4  85 10 0
 3 1  608260 247120 21267028 4374552 0  0      134272 0         2162 …