最近我被爱尔兰的AWS问题击中,丢失了一卷,需要尝试恢复.
我已将问题卷附加到/ dev / sdf –
我对此完全陌生,不完全确定发生了什么,但这看起来并不乐观>>
- > sudo fsck /dev/sdf
- fsck from util-linux-ng 2.17.2
- e2fsck 1.41.12 (17-May-2010)
- fsck.ext4: Superblock invalid,trying backup blocks...
- fsck.ext4: Bad magic number in super-block while trying to open /dev/sdf
- The superblock could not be read or does not describe a correct ext2
- filesystem. If the device is valid and it really contains an ext2
- filesystem (and not swap or ufs or something else),then the superblock
- is corrupt,and you might try running e2fsck with an alternate superblock:
- e2fsck -b 8193
运行fdisk -l / dev / sdf时…我收到>>
- sudo fdisk -l /dev/sdf
- Disk /dev/sdf: 8589 MB,8589934592 bytes
- 255 heads,63 sectors/track,1044 cylinders
- Units = cylinders of 16065 * 512 = 8225280 bytes
- Sector size (logical/physical): 512 bytes / 512 bytes
- I/O size (minimum/optimal): 512 bytes / 512 bytes
- Disk identifier: 0x00000000
- Disk /dev/sdf doesn't contain a valid partition table
更多信息运行后：
- > sudo mke2fs -n /dev/sdf
- Superblock backups stored on blocks: 32768,98304,163840,229376,294912,819200,884736,1605632
有人可以提供帮助,没有太多运行fsck的经验.
提前致谢！
编辑>>找到答案：
- > sudo mount -t xfs -o /dev/sdf /mnt/test-ebs
- XFS: Filesystem sdk has duplicate UUID - can't mount
- > sudo mount -t xfs -o nouuid /dev/sdf /mnt/test-ebs
- mount: Structure needs cleaning
- > sudo xfs_repair -L /dev/sdf
- ..
- .
- connected inode 9625284,moving to lost+found
- disconnected inode 9625285,moving to lost+found
- disconnected inode 9625286,moving to lost+found
- disconnected inode 9625287,moving to lost+found
- disconnected inode 17957583,moving to lost+found
- disconnected dir inode 17977810,moving to lost+found
- disconnected dir inode 17977835,moving to lost+found
- Phase 7 - verify and correct link counts...
- resetting inode 368465 nlinks from 2 to 4
- resetting inode 17977810 nlinks from 0 to 2
- ..
然后我又跑了这个sudo mount -t xfs -o nouuid / dev / sdf / mnt / test-ebs
全部现在工作！
干杯
在运行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
然后尝试在映像上使用testdisk以尝试恢复分区表.
另一种选择是在图像上使用photorec.这是一个非常好的工具,即使文件系统损坏也可以检测和查找文件.它可以恢复大量的文件格式.至少,您将能够获取数据.
