我有一台 MSI GL73-8RD，配有一个 SSD 和一个 HDD。我在 SSD 上安装了 Windows，并将一些文件存储在 HDD 中，然后对 HDD 进行了分区并在那里安装了 Ubuntu 18.04。
后来，Ubuntu 升级到了 20.04。我只需单击提示即可。显然，这导致 20.04 与 18.04 一起安装，但出于某种原因，我无法再在 18.04 安装上使用密码。
此外，Windows 更新后，20.04 只能在紧急模式下启动。我检查了几个问题，然后在日志中发现分区 /dev/sda7 有问题。我在这个分区上运行了 fsck，现在 20.04 即使在恢复模式下也无法启动。但是 Windows 10 和 18.04 仍然可以正常启动。
我需要从失败的 Ubuntu 安装中恢复一些重要文件。我认为硬件没有问题，所以文件应该还在那里。我该怎么做？
我是否应该先复制 HDD 的内容作为安全预防措施，然后尝试使用实时 USB 驱动器恢复文件？
是否有专门针对此问题的特定工具？我知道有专门用于数据恢复的工具，但我不知道哪一个是正确的。
编辑
根据 @vanadium 的建议，我启动了一个实时 USB 驱动器并尝试安装分区。由于我的安装非常脏，因此有两个与 Windows 相关的分区可以正常工作，一个名为“Computer”的位置和三个未命名的卷 /dev/sda4-5-7。
我试图挂载它们，但不幸的是，似乎包含我的数据的是 /dev/sda7，因此无法挂载。
@vanadium 指出 Testdisc 和 Photorec 是潜在的替代方案。我正在寻找有关这些工具的具体指导。
答案1
这取决于文件系统和最终分区的损坏程度。即使系统无法启动，文件系统仍可读取。
我将从安装 DVD 或 USB 启动实时会话，然后尝试挂载文件处于只读模式的卷。如果成功，您将能够将文件复制到另一个硬盘驱动器，而无需采取更高级的恢复措施。
如果失败，那么不幸的是，损坏非常严重，你可能需要求助于高级数据恢复。Testdisk 和 Photorec允许修复某些分区（Testdisk）并从磁盘上的二进制数据中恢复文件（Photorec）。
答案2
因此，在尝试了 @vanadium 提出的解决方案但无济于事后，我推断，由于驱动器没有受到冲击或没有吱吱作响，并且我中断了 Windows 更新，所以这可能是由 I/O 错误导致的逻辑故障。
我使用 SystemRescueCD 刻录了一个实时 USB 记忆棒，这是一个特殊用途的 Linux 发行版，它附带了一些在尝试修复安装时非常有用的实用程序。
我首先使用带有选项 -n 的 ddrescue 将损坏的分区复制到外部硬盘驱动器，我将其称为干净副本。-n 允许快速完成第一次操作，并将对读取头的损坏降至最低。正如我所猜测的那样，我能够读取分区中 100% 的字节。
然后我使用 dd 将干净副本复制到第二个外部硬盘上，即工作副本。这样可以确保如果我在工作副本上所做的任何工作具有破坏性，我可以返回到干净副本，而不必从可能出现故障的驱动器进行复制。
然后我在工作副本上的分区上运行了 TestDisk。按照菜单，我选择了分区，TestDisk 为我提供了故障文件系统中的超级块列表。
超级块是内存中包含有关文件系统结构的元数据的块。TestDisk 检测到文件系统是 ext4 文件系统，并提出了修复文件系统的命令：
fsck.ext4 -p -b <start of superblock> -B <size of superblock> /path/to/working/copy
参数 <超级块的起始> 和 <超级块的大小> 取自 TestDisk 的输出。
运行此命令后，第一个损坏的超级块已修复，文件可以全部访问。然后，我将它们备份到通常用于 Windows 备份的第三块硬盘上。
总成本：购买外部硬盘大约 200 美元。一家数据恢复公司报价 800 美元来完成这项工作。