我使用整个设备作为 LVM 物理分区，这样
sudo pvcreate /dev/xvdg
不幸的是，在使用它的时候，我通过编写一个新的分区表意外地覆盖了一些数据（我认为）：
sudo fdisk /dev/xvdg、添加新分区、写入分区表、删除分区、写入空分区表
这就是我目前的情况。一切似乎仍在正常运转，但我担心重启、卸载等......
- 它坏了吗？
- 如果是，那么最好的解决方法是什么？
谢谢！
答案1
假设您使用整个磁盘作为 lvm pv，而不是其中的单个分区，那么通常应该没问题，因为 LVM 头不在第一个扇区中，而分区表位于其中，尤其是在使用 512 字节扇区时。
分区表位于第一个扇区：例如这里：硬盘可以划分为一个或多个逻辑磁盘，称为分区。此划分记录在位于磁盘 0 扇区的分区表中。
LVM 头默认位于第二个扇区：例如这里：默认情况下，LVM 标签位于第二个 512 字节扇区中。您可以通过将标签放置在前 4 个扇区中的任意一个扇区上来覆盖此默认设置。如果需要，这允许 LVM 卷与这些扇区的其他用户共存。
注意：我不确定如果 fdisk 使用的扇区大小较大（比如说 1024 字节）会发生什么情况 - LVM 可能仍位于第二个 512 字节扇区中，而 fdisk 可能会覆盖整个 1024 字节扇区？
顺便说一句：如果您不确定并且可以访问额外的空间（例如在 Amazon EC2 上），您可以始终创建一个相同大小的卷，在其上执行 pvcreate，将其添加到卷组，使用 pvmove 将数据移动到新卷，然后使用 vgreduce 删除受影响的卷。
答案2
是的，在 99.99% 的情况下，它已经损坏。原因是您覆盖了分区表。lvm 的元数据位于 PV 的第二个 512 字节扇区中。因此，在创建新分区期间，如果您触碰了这些扇区，那么您的元数据就会被清除。本质上，重新启动、umount 会搞砸一切。
有两种可能（但可能不可行）的黑客攻击方式。
1) 如果您知道最后一个已知良好文件系统的确切分区表，则可以运行 fdisk 并尝试以完全相同的顺序创建它。您必须知道旧文件系统的起始和结束扇区。像以前一样创建分区，它可能会成功。
2) 如果事情没有按这种方式进行，那么还有另一种解决方法，即 pvcreate。您上次已知的 lvm 备份将存储在/etc/lvm/archive/volume_group_name_XXXX.vg文件中。您需要从那里获取 PV 的 UUID。然后，如果一切顺利，您可以这样做。
pvcreate --uuid <put_uuid_here> /etc/lvm/archive/volume_group_name_XXXX.vg <physical-volume name>
但是如果可以的话，请先备份您的数据。pvcreate 不会接触用户数据，它只处理元数据，但如果在启动时，fsck 发现任何不一致，它可能会导致 fs 错误和可能无法恢复的磁盘。