2

I had (paying attention to the past time here) a Centos 6.7 host who was migrated using Vmware conversion tool from a HyperV cluster. Therefore, the final configuration of its disks was:

/ dev / sda1 -> BOOT
/ dev / sdb1 -> Physical Volume
VG on / dev / sdb1
6 LVs on VG, root included

Time came and a logical volume was filled and VG did not have any free PEs to extend. So I made a ninja move and I extended /dev/sdb and went (wrongly) to rewrite the partition table to grow the PV. After that, the VM did not boot again because the LVM metadata was overwritten.

I tried several scenarios, the most successful was strings / dev / sdb | head -n 1000 where I found copies of the LVM information (from the auto backups it makes to each modification), created a file from what seemed to be the latest configuration, created a PV with uuid same as the original and --restorefile the specified file. I continued with vgcfgrestore and vgchange -ay and all logical volumes became visible, but mount fails and I get the bad superblock or wrong fs type error. I have the feeling that the boundaries of LVs are not correct and I have overlaps with the old structure, hence the problem with the filesystem during mount.

Has any of you seen anything like that? Can anybody suggest any solution?

kasperd
  • 30,455
  • 17
  • 76
  • 124
Nick Vidiadakis
  • 61
  • 2
  • 5

1 Answers1

1

If you have backups of the host configuration and data, it will be faster to reinstall the OS and restore.

Make a backup image of the LVs, such as with dd to a regular file, or perhaps a LVM snapshot. Run a file system repair tool on the backup, such as xfs_repair -f /backup/lv. This helps indicate if there is a recoverable file system.

Edit: you indicated ext4. Try all the superblocks as described over on UNIX Stack Exchange: Recovering ext4 superblocks. The linked data recovery page from the Ubuntu wiki has some file extraction utilities if you really need files that don't have a backup.

Personally, I prefer to create PVs on entire disks without a partition table, such as /dev/sdb. Resized disks can be added immediately.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Filesystem was ext4 and I run a "fsck.ext4 /dev/vg_name/lv_name" but it still responds with "Bad magic number in super-block while trying to open..." – Nick Vidiadakis Oct 26 '18 at 14:23
  • I don't think it is likely you will recover the file system intact. Try examining the superblocks using examples like one I linked in my edit. Then extract any valuable files from the image. – John Mahowald Oct 27 '18 at 11:52