LVM逻辑全分区的硬盘，superblock备份存放在哪？【LVM底层数据存储的方式】

wellbiao

公司的硬盘不能读取，错误信息是bad magic number,bad superblock.我想用备份的superblock来恢复硬盘，但是不知道LVM分区的根分区的底层数据存储还是不是和原来的普通分区一样呢？

请高手指点！最好是把他们的存储方式说一下，我个人很好奇，但是一直找不到相关的资料。

whoiswhoz

是硬盘的问题 还是lv的问题 又或者是文件系统的问题啊

bad magic number,bad superblock 这些是文件系统吧

wellbiao

是文件系统的问题，我看网上说可以用备份的superblock恢复。但是我的/分区和swap分区都是用的LVM分区的，不知道它的存储和普通的分区的区别，superblock备份的位置和它的关系，找不到相关的资料。


请有懂的高手，说一说，谢谢。

whoiswhoz

把出错的/dev/vg_id/lv_id 当成普通的分区不行吗？

我去试验下卡纳可能

michael1983

不明白楼主的意思

whoiswhoz

[root@localhost ~]# cat /cd/v1/aaa
vcnuiznvkjqr
[root@localhost ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1              6321524   4398020   1602208  74% /
none                     79228         0     79228   0% /dev/shm
/dev/mapper/testshotsanp-v1
                         99150      5655     88375   7% /cd/v1
[root@localhost ~]# umount /dev/testshotsanp/v1
[root@localhost ~]# mkfs.ext3 -n /dev/testshotsanp/v1  ##模拟格式化 查看超级块的位置
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
25688 inodes, 102400 blocks
5120 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

[root@localhost ~]# fsck.ext3 -b 8193 /dev/testshotsanp/v1   ##利用超级块修复
e2fsck 1.35 (28-Feb-2004)
/dev/testshotsanp/v1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (3557, counted=3567).
Fix<y>? yes

Free blocks count wrong for group #1 (7685, counted=7684).
Fix<y>? yes

Free blocks count wrong (93486, counted=93495).
Fix<y>? yes

Free inodes count wrong for group #0 (1965, counted=1964).
Fix<y>? yes

Free inodes count wrong (25677, counted=25676).
Fix<y>? yes


/dev/testshotsanp/v1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/testshotsanp/v1: 12/25688 files (16.7% non-contiguous), 8905/102400 blocks
[root@localhost ~]# mount /dev/testshotsanp/v1 /cd/v1/
[root@localhost ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda1              6321524   4398020   1602208  74% /
none                     79228         0     79228   0% /dev/shm
/dev/mapper/testshotsanp-v1
                         99150      5655     88375   7% /cd/v1
[root@localhost ~]# cat /cd/v1/
aaa         lost+found/
[root@localhost ~]# cat /cd/v1/
aaa         lost+found/
[root@localhost ~]# cat /cd/v1/aaa
vcnuiznvkjqr

这样可以吗？LZ前备份啊


参考：http://it.china-b.com/linux/xtgl/20090601/38485_1.html
http://www.enet.com.cn/article/2008/0311/A20080311178982.shtml
http://www.cnblogs.com/xuczhang/archive/2010/02/24/1672533.html

wellbiao

回复 6# whoiswhoz


    谢谢楼上的，这样做应该是可以的，现在我在dd if=/dev/sda of=/dev/sdb，把要修复的盘CLONE到另一个盘。再去修复，您的方法应该是可以的
但是找回SUPERBLOCK后，用FSCK 检查的时候可能会破坏数据，所以只能谨慎了，现在想把数据存储的过程全弄明白，才敢下手了。

whoiswhoz

我也是百度了下出来了  不到30min LZ自己小心

wellbiao

很重要的数据，不敢不谨慎。再谢

yddll

如果已经坏了，fsck不会更坏

如果没坏，fsck也不会把他特意搞坏