文件系统损坏的修复过程

admin管理员组

文章数量:1586761

最近碰到两次在做扩卷等操作时整个卷数据损坏丢失的情况，有必要记录下问题的处理过程。
如果你是晚班，遇到这种情况，突然一个卷不见了，你先做好下面两件事。
1 记录好你之前所有的操作命令，用以判断我们到底是哪出了问题
2 如是虚拟机，将这个虚拟机原封不动的clone一份。
3 如是物理机，你得考虑是否可从其他机器、从HA应用上恢复，比如我们标准的大机器群是同构的，可用以恢复。
当然，物理机极端的情况，数据非常重要，不可有任何差池，那么就挂一个nas卷，用dd命令吧整个物理块设备数据裸方式复制一份。

如何恢复丢失的数据呢？要想知弄清楚如何恢复，必须知道整个文件系统的层级。
简单的层级划分过程是：对纯块设备进行分区，加入LVM管理中（PV->VG->LV)，对LV进行文件系统格式化。

第一层 块设备，一般是磁盘
? 硬盘最基本的组成部分是由坚硬金属材料制成的涂以磁性介质的盘片，不同容量硬盘的盘片数不等。每个盘片有两面，都可记录信息。盘片被分成许多扇形的区域，每个区域叫一个扇区。盘片表面上以盘片中心为圆心，不同半径的同心圆称为磁道。硬盘中，不同盘片相同半径的磁道所组成的圆柱称为柱面。磁道与柱面都是表示不同半径的圆，在许多场合，磁道和柱面可以互换使用，我们知道，每个磁盘有两个面，每个面都有一个磁头，习惯用磁头号来区分。扇区，磁道（或柱面）和磁头数构成了硬盘结构的基本参数。
? 存储容量=磁头数×磁道（柱面）数×每道扇区数×每扇区字节数
? 这里我不得不提下磁盘阵列，由于实际IO下有多个硬盘在同时运转，实际和以上描述的并不相符，但是硬件厂商会帮助我们再做一层抽象，在磁盘控制器程序上按照上述原理虚拟实现。（其实这是多话，有点晕就忽略这句）
? 我们可以直接对一个裸设备进行操作吗？当然可以，我们在linux上看见的写文件经过了VFS（虚拟文件系统）、RFS（真实文件系统）、IO（设备IO)三层,VFS是linux为了对各类文件系统统一管理标准定义的一套操作接口。RFS，这是哥创造的词，也可以说是真正的文件系统吧，比如ext3、fat32等等，为了可以在linux上使用，除了按照自己文件系统格式向底层IO设备写数据外，还要满足VFS定义的接口。IO,我们谈到的对裸设备进行操作就是它了，具体的过程是将总线进行内存映射，或者是做直接的IO端口操作，过程不在这里展开，有兴趣的可以自己查询摸索。
? 对于这个块设备，你用fdisk -l，可以看到/dev/hda、/dev/hdb等信息

第二层，分区
? 简单的说分区就是将一个块设备“咔咔咔”，划分成逻辑的几份，然后在其上做文件系统格式化，你可以对不同的分区使用不同的文件系统，分区是由磁盘上相邻扇区组成的容器，分区是由简单数据结构定义的。文件系统，从另一方面说，是驻留在分区之内的数据结构。
? 为什么要做分区呢？不知道，分久必合，合久必分，谁都不想在一个大物理硬盘上就做一个文件系统，或者说为了便于管理，一个分区数据坏了，不至于影响另一个。
? 分区表，还记得之前说的磁盘吗，我们经常说的主引导扇（MBR)区位于硬盘1磁头1柱面1扇区，这里包含着512字节的数据，在BIOS加电后就是从这里自动读数据，加载程序。
? 在这512字节的数据末尾，有一段64字节的分区表数据，以80H或00H为开始标志，以55AAH为结束标志。
? 每个分区项占用16个字节，这16个字节中存有活动状态标志、文件系统标识、起止柱面号、磁头号、扇区号、隐含扇区数目(4个字节)、分区总扇区数目(4个字节)等内容。由于MBR扇区只有64个字节用于分区表，所以只能记录4个分区的信息。这就是硬盘主分区数目不能超过4个的原因。我们用fdisk操作时，看到的primary partition确实是1-3，为了支持更多的分区，引入了扩展分区及逻辑分区的概念。简单的说是划分一个extended，再在它基础上划分多个逻辑分区，好吧，在fdisk分区时都可以看见。
? 回到我们knows中的fdisk命令，有一长串字符、数字，其实你只需要将整个硬盘划分为一个主分区就行了，将类型标为LVM（e8），这个标示也是在前面提到的16字节中做的。我认为这一步做不做都无所谓，它并不影响其上的文件系统，更加重要的是该分区的其实边界。就好像TCP/IP七层协议一样，IP层有一位标示上一层是UDP，还是TCP，我们解析程序根本可以不管IP层对上层标示，完全按照自己认为格式去读取它。

第三层，LVM
在刚刚做的分区上，一般就可以直接进行文件系统格式化了，但我们觉得还不够，还要在其上做一层虚拟，称之为LVM，其实lvm也是一种文件系统，“分久必合，合久必分”，还记得分区吗，是把物理卷划分为不同的逻辑卷，这个LVM最大目的是把多个物理卷划到一个资源池中来，方便跨物理卷的管理。
好了，这个过程在这里省略（PV-VG-LV）

第四层，EXT3/4文件系统格式
总算，我们可以真实的在LV上ext文件系统格式化这个卷了。
有必要了解下EXT3文件系统的主要数据结构。它会将这个卷数据看成线性的，比如这个卷有1到1000 block，然后将这1000个block划分为多个组块。我们的数据结构从组块开始，每个组块里面有super-block、GDT、block bitmap、inode bitmap、inode table、data blocks
具体参见这里，这哥们都标清楚了。http://blog.csdn/onlyg/article/details/6833390
super-block：里面记录了整个文件系统的信息，不是所有的组块都含有它
GDT：组块描述表，记录当前组块以及其他组块的相关信息，这也解释了我之前提出的，为什么数据坏了，还能看到其他组块的信息。
inode：inode，可以解释为文件的元数据，记录文件的创建时间、大小、占用的块等等，inode bitmap则表明这个组块里面那些空间还可以用作inode，我们在划nas时不常常遇见inode不够，要多分一点空间吗，实际上就是把次位图调大，并放大后面的inode table空间。
inode table，不解释，是具体存放inode的地方。
data bitmap，data，放文件真实数据的地方。

好了，四层都说完了，你可以去喝杯水了，下面是具体的实际操作，以及一些恢复中的思考。

如何恢复

有了上面的基础知识，你首先要判断到底是那一层被破坏了。
第一层，不太可能，如果破坏了有硬件告警

第二层，是的，我们不小心把分区给删了，这不就破坏了吗
这是你用pvs看下这个分区是否还在pv中，不在的话很可能是已经破坏了。
查看/etc/lvm/backup/VGxxx，这个文件记录了vg所使用的pv，以及pv对于的物理分区。
我们可以参照这里重新划分分区（不要怕，前面已经说过，分区只对那64字节数据进行写，另外我们也有备份）
前面写那么多的重要原因是提醒各位，千万不要病急乱投医，比如很多同学就在这里用fsck（e2fsck/fsck.ext2/fsck.ext3）、
mkfs(mke2fs/mkfs.ext3/mkfs.ext2)等工具盲目check 物理设备，很可能就永远恢复不了了，记住，这些工具是第四层的，这里是第二层，只要分区就行了。

做完分区后就是重新建pv
pvcreate -ff --uuid xxxx-xxxx-xxxx --restorefile /etc/lvm/backup/vgxxxx /dev/xxx

恢复vg
vgcfgrestore -f /etc/lvm/backup/vgxxxx vgxxxx
到此，你可以用pvs、vgs、lvs看到你所有的东西已经恢复了。

第三层，我们很少在这一层出错，除非我们直接将vg干掉。
即便是真出问题，用vgcfgrestore可以马上恢复

第四层，前面pvs、vgs、lvs都可以了，但mount卷时还有问题，很可能将superblock破坏了，不要紧，这一层有这一层的恢复方法。
在这里，你操作的对象是lv，是vg中的逻辑卷，切记不要弄错。

首先用dumpe2fs查看LV中所有备份的superblock
root@localhost root# dumpe2fs /dev/vgxxxxx/xxx |grep super
dumpe2fs 1.32 (09-Nov-2002)
Filesystem features:? has_journal filetype needs_recovery sparse_super large_file
? Primary superblock at 0, Group descriptors at 1-1
? Backup superblock at 32768, Group descriptors at 32769-32769
? Backup superblock at 98304, Group descriptors at 98305-98305
? Backup superblock at 163840, Group descriptors at 163841-163841
? Backup superblock at 229376, Group descriptors at 229377-229377
? Backup superblock at 294912, Group descriptors at 294913-294913
? Backup superblock at 819200, Group descriptors at 819201-819201
? Backup superblock at 884736, Group descriptors at 884737-884737

尝试着使用备份superblock恢复
fsck.ext3 -b 63840 -y -n /dev/vgxxxxx/xxx
一个一个备份superblock试，只要你懂了整个层次，没有在低层次使用高层次工具对数据破坏，这样一般都是可以恢复的。、
完成后在用fsck检查一次。

先说这么多吧，大家看着办。

本文标签： 文件系统过程