---恢复内容开始---
只破坏super block（super block用于描述文件系统信息）
------------------------------------------------------
破坏前状态：
通过 dd if=/dev/zero of=/dev/sdb1 bs=4k count=1
/date目录发生故障
发现故障后第一件事先umount对应的磁盘，因为在线修复可能会丢失数据
（模拟环境无法卸载，直接重启,也可以使用lsof查询到具体占用的进程干掉即可）
无法挂载。
fsck -v /dev/sdb1
发现super-block块损坏，询问是否修复，一路yes下来，修复完成。
mount成功。数据没有丢失。
注：本例文件格式为ext4，如果文件格式为xfs，使用e2fsck -b block_number device修复即可。
---恢复内容结束---
破坏super block与大量inode_table/bitmap/等元数据信息以及data_block（会有数据丢失）
----------------------------------------------------------------
通过 dd if=/dev/zero of=/dev/sdb1 bs=4M count=250破坏大量文件
需要指定backup_super_block位置来恢复超级块文件
可以通过fdisk创建相同大小与文件格式的新空间来查找backup_super_block位置
查找到了backup_super_block位置
在ext文件系统下，也可以通过 mke2fs -n /dev/sdb来模拟创建过程，找出backup_super_block位置
利用mke2fs这个命令 mke2fs -n 设备名,为了不引起歧义，所以这里直接复制了原文解释。
-n Causes mke2fs to not actually create a filesystem, but display what it would do if it were to create
a filesystem. This can be used to determine the location of the backup superblocks for a particular
filesystem, so long as the mke2fs parameters that were passed when the filesystem was originally
created are used again. (With the -n option added, of course!)
简单来说就是接了-n 参数 ，mke2fs 不是真的在设备上创建文件系统，它只是模拟这个过程并显示给你看。让你明白它究竟做了那些事。
[root@server1 ~]# mke2fs -n /dev/sdb
mke2fs 1.41.12 (17-May-2010)
/dev/sdb is entire device, not just one partition!
无论如何也要继续? (y,n) y
文件系统标签=
操作系统:Linux
块大小=4096 (log=2)
分块大小=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
inodes, 2621440 blocks
blocks (5.00%) reserved for the super user
第一个数据块=0
Maximum filesystem blocks=2684354560
block groups
blocks per group, 32768 fragments per group
inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 --------------->>> 超级块的备份位置就在这里
[root@server1 ~]#
通过e2fsck -b superblock_number device来修复
找到正确的数字会提示修复
[root@localhost ~]# e2fsck -b 294912 /dev/sdb1 e2fsck 1.42.9 (28-Dec-2013) Superblock has an invalid journal (inode 8). Clear<y>? yes
错误的数字会直接结束
[root@localhost ~]# e2fsck -b 29491 /dev/sdb1
e2fsck 1.42.9 (28-Dec-2013)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
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 <device>
接着一路Y修复完成。
[root@localhost ~]# e2fsck -b 294912 /dev/sdb1 e2fsck 1.42.9 (28-Dec-2013) Superblock has an invalid journal (inode 8). Clear<y>? yes *** ext3 journal has been deleted - filesystem is now ext2 only *** /dev/sdb1 was not cleanly unmounted, check forced. Resize inode not valid. Recreate<y>? yes Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory. Clear<y>? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Root inode not allocated. Allocate<y>? yes /lost+found not found. Create<y>? yes Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(0--8481) +(32768--33024) +(98304--98560) +(163840--164096) +(229376--229632) +(294912--295168) Fix<y>? yes Free blocks count wrong for group #0 (24279, counted=24284). Fix<y>? yes Free blocks count wrong for group #8 (16384, counted=32768). Fix<y>? yes Free blocks count wrong (498130, counted=514519). Fix<y>? yes Inode bitmap differences: +1 +(3--10) Fix<y>? yes Free inodes count wrong for group #0 (8180, counted=8181). Fix<y>? yes Directories count wrong for group #0 (3, counted=2). Fix<y>? yes Free inodes count wrong (131060, counted=131061). Fix<y>? yes Recreate journal<y>? yes Creating journal (16384 blocks): Done. *** journal has been re-created - filesystem is now ext3 again *** /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb1: 11/131072 files (0.0% non-contiguous), 26153/524288 blocks
mount成功，但是我DD了太多，破坏了所有数据。
[root@localhost ~]# mount /dev/sdb1 /date [root@localhost ~]# cd /date/ [root@localhost date]# ls lost+found [root@localhost date]# ll total 4 drwx------. 2 root root 4096 May 20 08:31 lost+found