ubuntu – 通过fsck恢复

前端之家收集整理的这篇文章主要介绍了ubuntu – 通过fsck恢复前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
最近我被爱尔兰的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.这是一个非常好的工具,即使文件系统损坏也可以检测和查找文件.它可以恢复大量的文件格式.至少,您将能够获取数据.

猜你在找的Ubuntu相关文章