这将是一篇很长的文章，因为我不确定背景故事的哪些部分是相关的——如果你想跳过无聊的部分，你可以只阅读包含实际问题的最后两段。
长话短说，我粗心地使用分区实用程序，弄乱了我的分区，可能损坏了一些文件，因为当时正在进行分区调整大小操作，当我不得不终止实用程序进程时，文件被移动了。结果是磁盘上的最后一个分区（大约 420 GB）消失了，连同我机器的 /home 一起消失了。我的备份有点过时了，所以我决定尝试尽可能多地恢复，然后再清理。
我启动了一个用于数据恢复的实时 Linux 发行版，并启动了 Testdisk，看看它能否找到丢失的分区。第一次运行时，我将其设置为“Intel 分区”，使用快速而深入的搜索分析了磁盘，但一无所获。我想，既然我知道事故发生前的分区表是什么样子，我会使用 GParted 重新创建丢失的分区（不进行任何格式化），然后再试一次。使用 Intel 分区，Testdisk 仍然无法在磁盘末尾找到任何东西，所以我尝试使用“无分区”启动选项。这次分析成立我重新创建了分区，在文件列表中，我实际上可以看到我丢失的文件（以及我之前删除的大量文件）。成功了！
现在，我吸取了教训，要经常备份，并且要小心分区（我甚至不想碰那个被搞乱的硬盘，但意外总是会发生）。幸运的是，Testdisk 似乎挽救了局面，在我写这篇文章的时候，它正在将丢失的文件复制到外部硬盘上，但复制过程中有些事情让我感到困惑。
正如我之前提到的，我丢失的分区大小约为 420 GB。分区所在的硬盘总共有 1 TB。目前，Testdisk 已经运行了大约 15 个小时（我正在通过 USB2.0 复制文件，速度很慢），并df告诉我外部驱动器上目前有超过 900 GB 的内容。当我检查副本的内容时，似乎还没有那么多内容，尽管我可能错过了一些大文件。
Testdisk 如何从 420 GB 大小的分区复制超过 900 GB 的数据？是否有一些预分配空间用于复制已删除的文件，Testdisk 可以看到这些文件，但实际上无法恢复/不再存在？
答案1
答案是 testdisk/photorec 经常过度抓取。有时文件的开始标记、结束标记或大小已损坏，或者它做出了错误的猜测并抓取了比文件所需更多的扇区。然后另一个文件在这个区域中有一个指针，它再次抓取重叠的扇区。
因此现在文件 1 包含文件 1 的全部内容以及随机数据。文件 2 包含部分随机数据。通常，这些程序不能很好地处理碎片文件，这也会导致数据过度抓取。
为了确保尽可能地恢复，它不会跟踪其他文件的扇区，以防出错。因此，许多文件中都有相同的扇区。
我发现一些文件，例如 word 文档，它们显示 2gb，但是当打开并以新名称重新保存时，它们会恢复到正确的大小。
假设每个符号都是一个存储集群。
G 是 GIF 文件 W 是 word 文档 U 未使用
GGGGGWWWWUUUG
大多数文件都有页眉和页脚。因此，当扫描检测到 gif 页眉时，它会查找 GIF 的页脚。因此，现在恢复的 GIF 文件包含 GGGGGGGWWWWUUUG，因为文件是碎片化的。然后，当它向前扫描时，它会检测到 W 或 word 页眉和页脚，因此 word 文档正确地显示为 WWWW，尽管之前抓取过度。