![通过 fsck 恢复](https://linux22.com/image/558036/%E9%80%9A%E8%BF%87%20fsck%20%E6%81%A2%E5%A4%8D.png)
我最近在爱尔兰遇到了 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
然后尝试使用测试磁盘在图像上尝试恢复分区表。
另一个选择是使用照相记录在图像上。这是一个非常好的工具,即使文件系统损坏,它也能检测和查找文件。它可以恢复大量文件格式。至少,你可以恢复数据。