Busted OS distro but existing data implies creating a new OS instance, then block level restore data, and copy over select data files still remaining. Other options are possible depending on what backups exist; restores are a choose your own adventure where you need to think about the way forward.
Start installing the new host. Recommend root fs on LVM, based on other questions here about it filling up and needing to do some tricky partitioning.
LVM metadata
Backups of metadata in /etc/lvm/backup/ and /etc/lvm/archive/ are text files, logging all sorts of useful things: device WWN, PV name and ID, LV name ID and extent map, VG name and ID. Archive this, perhaps all of /etc, as a part of a host level backup of the old instance. However LVM operates from on-disk metadata. In the simple case VGs do not need this exact metadata to be imported or rebuilt.
Keep PVs or not
Decide whether to detach and reuse the disks from the old instance or not. Could be easy to swing over with virtual or SAN storage. Or could be not what you want to do, such as with old physical disks where you want to accomplish a storage migration.
Rescue mode
Either way, on the old host boot some rescue distro where you can do things to LVM. Run the commands pvs; vgs; lvs; to get a summary of LVM on the system. vgimportdevices --all; pvscan --cache should make PVs known to the system if they are not already. (In more complex recovery scenarios where LVM is missing something or is corrupted, this is where metadata backups are useful.)
Reusing disks
For the reuse disks option, it is prudent to deactivate and export the VG, so the old system will not attempt to use it. Examples you might see of this are under the use case of moving a VG to another system.
I have not provided examples of LVM arguments that will be different for you: VG, LV, PV, block devices. Read the documentation for usage details.
# Old host in rescue mode
umount
vgchange -an
vgexport
# Move disks to other system
# New host
vgimportdevices --all
vgimport
vgchange -ay
Not reusing disks
If swinging over disks is inconvenient, or you want to change VG or LV configuration, rebuilding VG then restoring data is an option.
Copying over the data can be done at the block level, which can be fast compared to file level restore. Important: copy the LVs, not the lower level PVs. If you have IP networking, the copy can be done via dd through ssh and/or netcat.
# Old host in rescue mode
vgchange -ay
umount
# snapshots optionally can capture a point in time while the origin is still in use
# lvcreate --snapshot
New host
vgcreate
be sure LVs are at least as large as the old LVs
lvcreate
Old host in rescue mode
dd if=/dev/vg/lv | gzip | ssh root@target 'gzip -d | dd of=/dev/vg/lv'
pvmove
If both old and new disks can be attached to the new host, the VG can be imported as is but then migrated to new PVs. Useful tool, either now during recovery, or in future storage migrations.
Follow the above reusing disks procedure to import the VGs.
vgextend # new PV
pvmove # old PV
vgreduce --all # empty old PVs
Validate applications function
With a new OS install and post storage migration, a check things function is a good idea.
Edit /etc/fstab and add the migrated volumes. Install and update applications. Reboot. Spot check applications start and do what they should.
