In some scenarios, there could be some reasons that a LVM PV failed, or the PV metadata is overwritten by a mistake. More likely you will get error message like below:
"incorrect metadata area header checksum"
or something about not being able to find PV with UUID ...
You may be able to recover the data the physical volume by writing a new metadata area on the physical volume specifying the same UUID as the lost metadata
Note: You should not attempt this procedure with a working LVM logical volume. You will lose your data if you specify the incorrect UUID.
Step1 Get UUID of the PV
Extract the exact uuid for the PV that was overwritten from the file /etc/lvm/archive/VolumeGroupName_XXXXX.vg. (Where XXXXX represents the number of the last known good archived lvm metadata).
Use command lvs to extract UUID of the PV
lvs -a -o +devices
-P) argument will enable you to find the UUID of the missing corrupted physical volume.
vgchange -an --partial
For some reason, you can't find uuid of the PV, then the last way to find it out is to search the PV
or anyway that could find out the UUID of the PV.
Step2, restore the PV metadata
Use pvcreate to restore the metadata:
pvcreate --uuid "<some_long_string>" --restorefile /etc/lvm/archive/VolumeGroupName_XXXXX.vg <PhysicalVolume>
If you are lucky you'll find that the on-disk lvm metadata takes at least so much space as what it was overwritten with. The above command has been know to recover a PV overwritten with mkswap. If whatever overwrote the VGDA writes past that area, LVs may be affected. In this case, fsck might be able to fix the filesystem on the LV, or you may need more drastic measures to pull data off of it. Contact your local friendly filesystem expert for help in that case.
Note: pvcreate only overwrites the lvm metadata areas on disk and doesn't touch the data areas (the logical volumes).
Step3, restore VG metadata
vgcfgrestore VGRestored volume group VG
Step4, Check VG, LV and PV
lvs -a -o +devices
lvchange -ay /dev/VG/stripe