前几天,当我在Vmware下的
Linux客户端上扩展磁盘时,我有一个适当的大脑放屁时刻.我将Vmware磁盘文件扩展到所需的大小然后我做了我通常在没有LVM的Linux客户端上做的事情:我删除了LVM分区并重新创建它,从与旧版本相同的位置开始,但扩展到新的大小磁盘. (其后是fsck和resize2fs.)
然后我意识到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来恢复与之前完全相同的大小和磁盘位置吗?是否还有其他工具可用于查找和恢复文件系统? (显然,问题不在于我是否应该从一开始就以不同的方式做到这一点,我知道.这是一个关于当狗屎已经击中粉丝时该怎么做的问题.)