☰

使用 ddrescue 恢复损坏的驱动器。我可以在运行完成之前检查进度吗？

tag-icon • tag-icon hard-drive hard-drive-recovery ddrescue
使用 ddrescue 恢复损坏的驱动器。我可以在运行完成之前检查进度吗？

我目前正在运行ddrescue一个发生故障的驱动器。它已经运行了大约 16 个小时，目前仍处于拆分故障块阶段，但已经以 0 B/s 的速度运行了一段时间。我正在直接复制到另一个驱动器上，而不是制作映像。

我可以检查一下取得了哪些进展吗？或者这是否会扰乱某些事情？故障驱动器上只有一个我真正需要的项目，我只是想检查这些文件是否已经复制过来。

我运行的命令是：

ddrescue -d -f -v /dev/sda5 /dev/sdc2 /media/username/USB/rescue.logfile

我在 Ubuntu 上运行，如果这很重要的话，旧驱动器操作系统是 Arch。

答案1

理论上，您可以终止 ( ctrl+ C)ddrescue并在稍后使用相同的日志文件运行它，以使其继续而不是重新开始。我看到一些帖子声称这种方法并不总是有效 - 在这些情况下，ddrescue忽略了以前的工作并从头开始，原因不明。

尝试以只读方式挂载目标分区：

sudo mount -o ro /dev/sdc2 /mnt/foo

作为只读文件，它不应该影响ddrescue操作。存在文件系统的关键数据尚未恢复的风险，在这种情况下mount将失败。如果运气好的话，您可能能够挂载，然后读取所需的文件，但即使您没有收到和的错误mount（例如），文件也可能已损坏。检查它们或它们的副本。除非您确保文件有效且内部没有未恢复/混乱的碎片，否则cp不要终止。ddrescue

如果出现任何问题，您可以等待ddrescue恢复更多数据（如果有）。我不会等待未损坏的文件出现在挂载点下，因为系统可能会缓存元数据或文件本身等。请umount等待恢复更多数据，mount然后再次检查文件。

编辑：回答其他问题。

有没有办法告诉 ddrescue 指定一个特定的文件夹？

不。该工具在块级别工作。它对文件系统和文件一无所知。您的语句“ddrescuelog 说我的 99.73% 的文件已恢复”应该说“99.73% 的块”。

另外，数据是否可能已经恢复，因为上面说恢复了 99.73%，但损坏程度太严重，无法识别为文件？如果是这种情况，是否有程序可以查看损坏的文件，也许我可以手动恢复其中的一些。

可能的情况：文件内容恢复，但相应的文件系统条目未恢复（注意：一般来说，相反的情况也是可能的，但显然不是你的情况）。你说整个文件夹都不见了。我认为一些文件可能会在lost+found之后出现fsck（或以类似的方式出现，具体取决于你的文件系统——我不知道是什么）。

更多信息请点击这里：Linux 和 Unix 中的 lost+found 文件夹有什么用途？

此fsck操作不是只读的，因此不应在ddrescue正在运行的时候执行。终止ddrescue、运行fsck和恢复ddrescue也是不好的做法。最好等待ddrescue完成。这可能需要一些时间 – 阅读这和这。

一般情况下，你应该使用fsck（或任何其他非只读工具）恢复数据的副本。这是个不错的方法，供将来参考：

  1. 写入文件，而不是设备。使用文件系统写时复制 (COW)特征。
  2. 做一个奶牛使用 进行复制cp --reflink=always。您可以在ddrescue操作过程中执行此操作。此副本就像是目标文件的快照。
  3. 在副本上使用任意工具，包括非只读工具。
  4. 如果发生故障，您仍然可以使用原始目标文件（如果ddrescue仍在运行，可能会恢复更多数据）重新开始另一个奶牛复制（也许使用不同的工具）。

您也可以尝试搜索已删除的文件并恢复它们。工具的选择取决于文件系统。

另一个提示：也许您的软件正在文件系统层次结构中的其他地方使用临时文件。检查/tmp/, /var/tmp/。

编辑，回答附加问题。

当 ddrescuelog 说 99.73% 的块已恢复时，这到底是什么意思？听起来我应该期待一些结果，而不是一个空的主驱动器。

注意：下面的示例并非旨在涵盖所有文件系统问题和场景，也不旨在区分磁盘扇区和文件系统分配单元；它仅用于回答问题。

想象一下您的分区是一本书 – 一本百科全书，而不是一本有情节的小说。文件是其中的文章。磁盘块（或扇区）就像书中的一页。文件系统是将文章放在页面上的一般方法。有些页面包含目录 (ToC)在我们的图片中这是一个文件系统问题，可能看起来像这样：

文章＃289：第 2076、2077、2078、402、403 页。

请注意，本文是一份文件，内容可能非常零散。在另一页上，但仍在目录我们有类似的文件夹结构：

…
people/： 看目录在第 43 页。
…
（第 43 页）
mathematicians/：参见目录参见第 80 页
famous Poles/。目录在第 82 页。
Adam and Eve：参见文章 #14。...
（
第 80 页）
Euclid：参见文章 #289。
Banach Stefan：参见文章 #4380。...
（
第 82 页）
Banach Stefan：参见文章 #4380。
Kościuszko Tadeusz：参见文章 #2208
。...

此结构是硬链接文件的示例。至少有两个路径指向单个文章：./people/mathematicians/Banach Stefan和./people/famous Poles/Banach Stefan。在这里，我将点放在每个路径的开头，因为我的示例故意隐藏了以下信息：people/section 属于哪个部分？（也可能是/people/或/full articles/people/或/stubs/people/或/foo/bar/people/）。

这目录可能还会有一段内容如下：

“空”页面：567、568、569、2070、2071…

即使给定页面上不属于任何当前存在的文章，它上面也有文本（即数据）。这是因为文章删除过程只会影响目录。 这目录是唯一可以确定某个页面是否属于某篇文章、属于哪篇文章，或者是否可以将其视为空页面并进行覆盖的方法。此外：没有办法在没有目录。百科全书有空白页作为条目的一部分，但充满 s 或空格或其他任何东西的扇区0可以作为文件的一部分，这感觉很奇怪。这都是关于目录。

您的某些页面（区块）尚未被拯救。其中任何一个页面都可能是包含文章数据的页面，或者目录-元数据。可能性：

  • 缺失的块是数据块（例如，第 2078 页）。您知道有关 Euclid 的文章的路径以及它位于哪些页面上，但其中一页是空白的，而它不应该是空白的。这篇文章无效。
  • 缺失的块是元数据块。一些场景：
    • 您失去了对可用空间的追踪。
    • 您知道有./people/mathematicians/Euclid路径，但您不知道文章在哪一页。除非您已经知道一些关于它的信息，否则不可能找到这篇文章（例如，关于某人的条目很可能包含单词“born”；PDF 文件以“%PDF”开头）。
    • 您知道某某页面上只有一篇文章，但没有完整的路径。在这种情况下，您可以将其放在下面lost+found，这样fsck做就可以了。在我们的图片中，有以下几种可能性（其中包括）：
      • 缺少第 80 页：您知道（从第 43 页）有mathematicians一个部分（文件夹），但您不知道文章 #289 应该以“Euclid”的名称包含在其中。
      • 缺少第 43 页：您不知道应该有关于亚当和夏娃的第 14 篇文章，也不知道应该有关于数学家和波兰名人的部分；但您可以看到（第 80 页）其中有一节包含关于欧几里得和巴拿赫的文章，而另一节（第 82 页）包含关于巴拿赫和科希丘什科的文章。这也许就是您所遇到的情况/home。文章（文件）在那里，可能有效。无法通过路径访问它们，因为您没有目录你的/home。
  • 如果有多个块未恢复，则可能出现上述问题的任意组合。
  • 缺失的块可能会被标记为空。在这种情况下，您不会有任何损失。

相关内容