通过发出以下命令,我能够用一个可用的和一个损坏的磁盘启动一个破损的raid 1系统。
mdadm --assemble --force /dev/md9 /dev/sda1 /dev/sda2
我能够从磁盘上复制VMWare映像,并用VMWare命令修复它
vmkfstools -x repair /path/to/image.vmdk
以便将其安装在ESXi上。 修复后,图像从GSX转换为ESXi格式。
我能够在新的Ubuntu安装中挂载磁盘( /dev/sdb1分区),但在尝试救援/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文件夹中。
这个可怕的事故有什么select吗?
首先,你迫使RAID组装。 其中一个磁盘可能比另一个有更老的数据版本。 通过强制它,你告诉md这两个磁盘包含相同的数据,并假设他们是干净的。 所以MD可以自由地从任何一个驱动器上取下任何部分。
你应该做的第一件事就是使用像dd这样的工具来获取驱动器的完整副本。 然后,所有的恢复工作都应该针对该文件而不是驱动器。
可能你太迟了。
现在你有两个select。
首先是把硬盘发送给一个商业数据恢复公司,如Kroll OnTrack。 这可能是昂贵的。 我有他们的账单从250美元到5000美元。 但是,如果你的数据是值得的,那么这是值得的。
如果在这一点上你不关心任何进一步的数据丢失,那么你的第二个select是尝试使用dd自己恢复。 closures驱动器并断开之前报告为失败的驱动器。 然后从急救光盘启动服务器并使用dd将驱动器复制到另一个驱动器。 要知道,在这个时候你可能会在原始驱动器上做的任何工作只会让商业数据恢复公司在以后认为自己头昏脑胀时难以帮助你。
在运行e2fsck -f -y / dev / sdb1之后,/ var / www中绝对没有数据,而且生成的数字文件名的大量文件现在位于lost + found文件夹中。
这些将是“丢失”的文件(inode与应该存在的链接,但不)。
fsck “find”他们,把它们放在这里给你。 您现在应该检查它们并确定哪些是重要的。
是的,这可能会 – 也许会 – 是一个巨大的任务,但如果你幸运的话,你会在那里find/var/www丢失的文件。
grep可能会成为你新的最好的朋友。