有一天，我有一个正确的大脑放屁时刻，同时在Vmware下的Linux guest虚拟机上扩展磁盘。 我把Vmware磁盘文件扩展到所需的大小，然后我做了我通常在没有 LVM的Linux客户机上做的事情：我删除了LVM分区并重新创build，从旧的那个开始，但扩展到新的大小磁盘。 （后面会跟着fsck和resize2fs。）
然后我意识到，LVM的行为与原始分区上的ext2 / 3/4的行为不同……在从最近的备份恢复Linux客户机之后（幸运的是，只有五个小时之前才采用），我现在很好奇我怎么能从下面的情况恢复。 毕竟几乎可以保证我将来也会变傻。
具有一个磁盘的虚拟Linux客户机，分区为256MB的一个/ boot（主）分区（/ dev / sda1），其余分区为逻辑分区（/ dev / sda5）。
然后将/ dev / sda5设置为具有pvcreate的物理卷，并使用通常的vgcreate命令在其上创build一个卷组（vgroup00）。 然后将vgroup00分成两个逻辑卷root和swap，用于逻辑上的/和swap。 /是一个ext4文件系统。
由于我备份了坏掉的guest虚拟机，因此我可以使用/ etc / lvm / backup下的备份LVM设置中的vgcfgrestore重新创build卷组，并使用与物理卷相同的UUID。 运行这个之后，我有两个与前面相同大小的逻辑卷，其中有4GB的空闲空间用于扩展磁盘。
但是，当我试图运行“fsck / dev / mapper / vgroup00-root”时，它抱怨一个破损的超级块。 我试图通过运行“mke2fs -n / dev / mapper / vgroup00-root”find备份超级块，但是没有一个工作。 然后我尝试运行TestDisk，但是当我要求它查找超级块时，它只给出了由于文件系统损坏而无法打开文件系统的错误。
因此，在Ubuntu Server 10.04 64位版LVM2的默认分配策略中，是否有可能从卷组的末尾分配逻辑卷？ 这肯定会解释为什么还原的逻辑卷不包含预期的数据。 我可以通过重新创build与以前的大小和磁盘位置完全相同的/ dev / sda5来恢复吗？ 有没有其他工具可以用来查找和恢复文件系统？ （显然，问题不在于我是否应该从一开始就以不同的方式做到这一点，我知道，这是一个关于什么时候该做什么事情的问题）。
每次您使用LVM执行操作时，默认情况下，先前的元数据将归档到/etc/lvm/archive 。 你可以使用vgcfgrestore来恢复它，或者用手抓住延伸（更难，但lvcreate(8)应该覆盖它）。
编辑：
为了尽可能简单，我应该补充一点，你可以在破坏性操作之前通过查看描述find最后的备份：
# 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'"
编辑：
normal分配策略（默认分配策略）将在有足够空间时从第一个空闲PE分配一个分段。 如果要确认LV的分配位置，可以查看档案文件，这些档案文件完全可以被人读取。
没有任何真正的恢复选项，没有任何工具可以支持我的知识。 但是，有关手动恢复的一些文章，请参阅LVM数据恢复部分的危险和注意事项 。
一般情况下，最好对损坏的卷或底层磁盘进行原始映像备份，并在备份版本上进行数据恢复，以便重新进行恢复。
上面的答案也有关于调整LVM卷大小的一节 – 扩展它们是相当安全的，通常使用lvresize而不是删除和重新创build。
在相关的一点上：既然你使用的是VMware，你还应该注意硬盘写caching刷新（写入障碍）通过pipe理程序和任何主机操作系统从客户Linux内核中正确地传播。 访客FS和客户内核中设置的写入障碍也很重要，应该是2.6.33或更高。