I have a 4 drive LVM PV Group. I had one drive fail (Ok, I broke it installing it in a new case.) so I swapped it for another drive and recovered the remaining data.

After a reboot I got stuck at a file system scan for the /dev/mapper/storage-storage1 LVM. I canceled that and rebooted with the fastboot flag to skip it. I ran fsck on the /dev/mapper/... device and it ran for awhile before I ran out of RAM and it failed. Now 2 of the physical drives show no partition table and are missing from the VG. They did have one LVM partition spanning the entire drive on each.

I want to get rid of this LVM and set up a RAID5 configuration anyway but I would have liked to backup some of the data on the LVM first. (Nothing that can not be downloaded again but it would save a lot of time to backup locally first.)

Is there anything I can try to recover the missing partition info on the two drives? The host OS is Debian 7 with OpenMediaVault.

2 Answers 2


For anyone having the same issue,

I used the PV Create command with the UUID set with the old UUID. LVM does not require a partition map so it was still able to see the data. I have to dig a little to figure out which UUID belonged to which drive. in the end I just guessed. If only one drive is missing you obviously use the missing UUID.

If you guess, mount the filesystem read only and check files. If your finding corrupt files unmount and swap the UUID's (Assuming you have more than one drive missing)

I still dont know what caused this issue. But the steps above solved it long enough for me to snatch some data I wanted. So I am happy.


It sounds like all the LVM structures are intact, which makes things somewhat easier. You can recover what data you can using the below steps.

Make an image copy of the LV

Put this somewhere with lots of space so you can work on it. dd_rescue works well for this. While you can work on the original, this lets you revert back to where you started when... uh... if something goes wrong simply by making the copy again.

Pick through the ruins with a digital forensics program

The free tool Autopsy can do this. It's not as user-friendly as dedicated Windows recovery tools, but it's better for first timers than The Sleuth Kit. The Sleuth Kit lets you really get into filesystem structures, but its learning curve is pretty steep.

Autopsy, on the other hand, isn't too bad. Here's a step by step set of instructions for using Autopsy

What caused the data loss?

Even though it may look like only one drive failed, you have another problem hiding in there somewhere or you wouldn't have this problem. Some of the data "recovered" by your RAID-5 wasn't valid. You might want to look into something with better data integrity assurances (ZFS, btrfs, etc.)

  • The LVM Can not be mounted because it is missing drives. They are there and appear to still contain data but there is no partition map. There was no RAID 5 setup.
    – JpaytonWPD
    Commented Feb 3, 2016 at 11:52
  • When you said you were reading the LV with fsck and running out of memory, it sounded like the LV could be opened and read despite the disk issues. The above general process can still work, but instead of being filesystem-oriented you would image the underlying disk devices, reconstruct the missing partition tables by hand, activate the images as a RAID-5 group, and hope there's enough RAID metadata to activate it. If not, the recovery becomes a job for the professionals unless you REALLY want to learn a bunch of new things in the process. Commented Feb 3, 2016 at 14:51
  • Again, there is no RAID5. There is no metadata. The data on the lost drive is lost forever (Unless I physically repair the drive.) I did already wipe the drives and have made a Software RAID5 group with them though. The LVM was easy to remount without a partition map. (The LVM partition is just an identifier.)
    – JpaytonWPD
    Commented Feb 4, 2016 at 1:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .