然后我意识到LVM在原始分区上的行为与ext2 / 3/4的行为不同……从最近的备份中恢复Linux客户机(仅提前五个小时,幸运的是)我现在很好奇我如何从以下场景中恢复过来.毕竟几乎可以肯定我将来也会变得愚蠢.
具有一个磁盘的虚拟Linux guest虚拟机,分区为256MB的一个/ boot(主)分区(/ dev / sda1),其余分区位于逻辑扩展分区(/ dev / sda5)中.
然后将/ dev / sda5设置为具有pvcreate的物理卷,并使用通常的vgcreate命令在其上创建一个卷组(vgroup00).然后将vgroup00分成两个逻辑卷root和swap,逻辑上用于/和交换. /是一个ext4文件系统.
由于我对已损坏的guest虚拟机进行了备份,因此我可以使用/ etc / lvm / backup下的备份LVM设置从vgcfgrestore重新创建卷组,并为物理卷提供相同的UUID.运行后我有两个逻辑卷,大小与之前相同,有4GB的可用空间,我已经拉伸了磁盘.
但是,当我试图运行“fsck / dev / mapper / vgroup00-root”时,它抱怨了一个破碎的超级块.我试图通过运行“mke2fs -n / dev / mapper / vgroup00-root”找到备份超级块,但这些都没有.然后我尝试运行TestDisk但是当我要求它找到超级块时,它只是由于文件系统损坏而导致无法打开文件系统的错误.
因此,对于Ubuntu Server 10.04 64位中LVM2的默认分配策略,是否可能从卷组的末尾分配逻辑卷？这肯定会解释为什么恢复的逻辑卷不包含预期的数据.我可以通过重新创建/ dev / sda5来恢复与之前完全相同的大小和磁盘位置吗？是否还有其他工具可用于查找和恢复文件系统？ (显然,问题不在于我是否应该从一开始就以不同的方式做到这一点,我知道.这是一个关于当狗屎已经击中粉丝时该怎么做的问题.)
解决方法
编辑：
为了使它尽可能简单,我应该补充一点,你可以通过查看描述在破坏性操作之前找到最后一个备份：
# grep description /etc/lvm/archive/vg01_* /etc/lvm/archive/vg01_00001.vg:description = "Created before executing 'lvremove -f /dev/vg01/foo'" /etc/lvm/archive/vg01_00002.vg:description = "Created before executing 'lvremove -f /dev/vg01/bar'" /etc/lvm/archive/vg01_00003.vg:description = "Created before executing 'lvremove -f /dev/vg01/baz'"@H_403_23@编辑：
正常分配策略(默认值为1)将在有足够空间时从第一个空闲PE分配条带.如果要确认LV的分配位置,可以查看存档文件,这些文件完全可以被人类阅读.
