记一次数据盘挂载mount: wrong fs type, bad option, bad superblock on devvdb1的排查

背景：

重启后数据盘挂载不上，报错如下： mount: wrong fs type, bad option, bad superblock on /dev/vdb1

（注意：任何操作请务必先给自己的盘做下快照备份，部分图为后补）（注意：任何操作请务必先给自己的盘做下快照备份，部分图为后补）（注意：任何操作请务必先给自己的盘做下快照备份，部分图为后补）

现场：1，看下现场，这个报错尝试先使用不同的文件系统挂载试下均不可

mount -t ext2 /dev/vdb1 /mnt mount -t ext3 /dev/vdb1 /mnt mount -t ext4 /dev/vdb1 /mnt

破局：2，尝试使用fsck修复，报错如故

3，找台正常的机器获取一下磁盘相关信息

e2fsck -f /dev/xvdb1

3.1 e2fsck是检查ext2、ext3、ext4等文件系统的正确性, -f 即使文件系统没有错误迹象，仍强制地检查正确性。

dumpe2fs -f /dev/xvdb1 |grep -i superblock

3.2 dumpe2fs 会显示 superblock 上的档案系统资讯和每个区块组 (block group) 的资讯，在一般拥有很多区块组档案系统，输出会非常多，因此加上grep过滤一下superblock

(-f 的参数，英文不好，就不翻译了，，，force dumpe2fs to display a filesystem even though it may have

some filesystem feature flags which dumpe2fs may not understand (and which can cause some of dumpe2fs’s display to be suspect).) mkfs.ext4 -n /dev/xvdb1

3.3 看下如果ext4格式化的话对应的相关信息（-n 不真正创建文件系统，只是显示创建的信息）

3.4 利用工具e2fsck，修复文件系统（指定superblock，可以对照dumpe2fs获取到得备份的superblock起始位置）

e2fsck -f -b 32768 /dev/xvdb1

3.5 重新挂载即可恢复

恢复：4，检查文件系统的正确性，失败

5，获取superblock失败

6, 尝试修复

将基本面的那些superblock全部测试了一遍，都不行

脑洞：

7，安装testdisk，检查一下这块数据盘不做赘述，可参考http://www.oschina.net/p/testdisk

8，找个windows的虚机，使用diskgenius扫一下

在这我使用的是挂windows虚机上使用磁盘工具扫描，但是什么也没扫到，连文件系统都没扫描到，这个是不应该的

迷之尴尬：9，检查history对xvdb盘的操作（不一定全）10，与系统管理员确认了一下之前的数据目录名称，全盘扫了一下，发现了两个疑似的目录，确认是数据目录

彩蛋：原来之前的管理员分区后没有格式化，直接写到了fstab里面，这也是为什么我们看到的fstab是挂载了数据盘，但是实际无法使用的原因 ：）