我最近在爱尔兰遇到了 AWS 问题，丢失了一个卷，需要尝试恢复。
我已将问题卷附加到 /dev/sdf -
我对此完全陌生，不完全清楚发生了什么，但这看起来不太有希望>>
> sudo fsck /dev/sdf
来自 util-linux-ng 2.17.2 的 fsck
e2fsck 1.41.12（2010 年 5 月 17 日）
fsck.ext4：超级块无效，正在尝试备份块...
fsck.ext4：尝试打开 /dev/sdf 时超级块中的魔数错误
无法读取超级块或超级块未描述正确的 ext2
文件系统。如果设备有效并且确实包含 ext2
文件系统（而不是交换或 ufs 或其他文件系统），然后是超级块
已损坏，您可以尝试使用备用超级块运行 e2fsck：
e2fsck -b 8193
运行 fdisk -l /dev/sdf... 时我收到>>
sudo fdisk -l /dev/sdf 磁盘 /dev/sdf：8589 MB，8589934592 字节 255 个磁头、63 个扇区/磁道、1044 个磁柱 单位 = 16065 * 512 = 8225280 字节的柱面 扇区大小（逻辑/物理）：512 字节 / 512 字节 I/O 大小（最小/最佳）：512 字节 / 512 字节 磁盘标识符：0x00000000 磁盘 /dev/sdf 不包含有效的分区表
运行后了解更多信息：
> sudo mke2fs -n /dev/sdf 存储在块上的超级块备份：32768、98304、163840、229376、294912、819200、884736、1605632
有人可以提供帮助吗，运行 fsck 方面没有太多经验。
提前致谢！
编辑>>找到答案：
> sudo mount-t xfs-o /dev/sdf/mnt/test-ebs XFS：文件系统 sdk 具有重复的 UUID - 无法挂载
> sudo mount-t xfs-o nouuid /dev/sdf /mnt/test-ebs 安装：结构需要清理
> sudo xfs_repair -L /dev/sdf .. 。 已连接 inode 9625284，正在移至 lost+found 已断开 inode 9625285 的连接，正在移至 lost+found 已断开 inode 9625286，正在移至 lost+found 已断开 inode 9625287 的连接，正在移至 lost+found 已断开 inode 17957583，正在移至 lost+found 已断开目录 inode 17977810，正在移至 lost+found 已断开目录 inode 17977835，正在移至 lost+found 第 7 阶段 - 验证并更正链接数... 将 inode 368465 nlinks 从 2 重置为 4 将 inode 17977810 nlinks 从 0 重置为 2 ..
然后我再次运行这个 sudo mount -t xfs -o nouuid /dev/sdf /mnt/test-ebs
一切正常！
干杯
答案1
在运行 fsck 之前，先制作文件系统的映像，然后对其进行操作。这样，如果出现问题，您还有原始文件。不要对文件系统本身进行操作。
此外，sdf 不太可能是文件系统，sdf 是驱动器本身，文件系统位于驱动器上的某个分区。运行 fdisk -l /dev/sdf 查看分区，然后尝试对 /dev/sda1 执行 fsck，等等。
准备设备的图像：
# dd if=/dev/sdfX of=sdfX.img
其中 X 是分区号，如 fdisk -l 所列出的。
然后在图像上运行 fsck：编辑：（注意，您不能直接使用 fsck，而是需要告诉 fsck 这是什么类型的文件系统）
# fsck.ext3 sdfX.img
当 fsck 修复分区后，按如下方式挂载它：
# mount -o loop sdfX.img /mnt/somedir
根据您的评论，fdisk 没有列出任何分区 - 这可能意味着分区表也丢失了。
再次制作整个设备的图像，然后：
# dd if=/dev/sdf of=sdf.img
然后尝试使用测试磁盘在图像上尝试恢复分区表。
另一个选择是使用照相记录在图像上。这是一个非常好的工具，即使文件系统损坏，它也能检测和查找文件。它可以恢复大量文件格式。至少，你可以恢复数据。