通过发出以下命令，我能够启动一个具有一个可用磁盘和一个损坏磁盘的损坏的 raid 1 系统。
mdadm --assemble --force /dev/md9 /dev/sda1 /dev/sda2
我能够从磁盘复制 VMWare 映像并使用 VMWare 命令进行修复
vmkfstools -x repair /path/to/image.vmdk
以便将其安装到 ESXi 上。修复后，映像从 GSX 格式转换为 ESXi 格式。
我能够/dev/sdb1在全新 Ubuntu 安装中挂载磁盘（分区），但在尝试救援/var/www和发布时ls -al我得到以下输出。
该命令fsck -y /dev/sdb1未报告任何失败。
该命令fdisk -l /dev/sdb报告以下内容。
我该怎么做才能获取数据/var/www？
更新 1：
运行e2fsck -f -y /dev/sdb1开始修复很多故障。但我怀疑这能否让我恢复数据。
更新2：
运行后，文件夹e2fsck -f -y /dev/sdb1中完全没有数据，/var/www并且有很多带有生成的数字文件名的文件lost+found。
这场可怕的事故之后还有什么解决办法吗？
答案1
首先，您强制组装 RAID 时搞砸了。其中一个磁盘的数据版本可能比另一个磁盘旧得多。通过强制组装，您告诉 md 两个磁盘包含相同的数据，并假设它们是干净的。因此，md 可以自由地从任一驱动器中拉出任何扇区。
您应该做的第一件事是使用 之类的工具对驱动器进行完整复制dd。然后，您所有的恢复工作都应该针对该文件，而不是驱动器。
你可能已经太晚了。
现在您有两个选择。
第一种是将驱动器送到 Kroll OnTrack 等商业数据恢复公司。这可能很昂贵。我收到过他们寄来的账单，金额从 250 美元到 5000 美元不等。但如果您的数据值得，那么这样做就值得。
如果此时您不介意进一步丢失数据，则第二个选择是使用 尝试自行恢复dd。关闭驱动器电源并断开先前报告为故障的驱动器。然后从救援 CD 启动服务器并使用dd将驱动器复制到另一个驱动器。请注意，此时您可能对原始驱动器进行的任何工作只会使商业数据恢复公司在您以后决定陷入困境时更难为您提供帮助。
答案2
运行 e2fsck -f -y /dev/sdb1 后，/var/www 中完全没有数据，并且许多具有生成的数字文件名的文件现在位于 lost+found 文件夹中。
这些可能是“丢失”的文件（带有应该存在但实际上不存在的链接的 inode）。
fsck“找到”它们并将它们放在这里供您使用。您现在应该查看它们并确定哪些是重要的。
/var/www是的，这可能（并且很可能）是一项艰巨的任务，但如果你幸运的话，你会从中找到丢失的文件。
grep可能会成为你最好的新朋友。