Recover data from corrupted LVM partition with TestDisk?

3

I had setup 3 disks in a LVM array with each disk holding some data. A few weeks back one of the disks "disappeared" from the LVM array and BIOS. After rebooting, the disk reappeared but does not display any of the data that was in it. The drive held a collection of ebooks that I can't easily rebuild so I'm keen to see if I can recover the data on it.

I'm trying to use TestDisk but have had little success so far. When I launch TestDisk to analyze the drive, I get the following message:

Initial Testdisk Output

Once I finish the Quick Search, I get an error about the Hard disk size being too small:

After Quick Search

I can then see that there are two partitions:

Partition Info

Trying to list the files however, just throws an error message:

Filesystem error

From GParted, It seems like the CHS settings detected by TestDisk are correct so the Disk too small error is a little baffling:

Gparted

I'm using TestDisk 6.13 on Ubuntu 12.04 LTS. Any suggestions on how I should proceed from here?

avggeek

Posted 2013-09-22T06:35:52.100

Reputation: 165

Answers

0

I wonder if the problem you are having is that Testdisk is looking for useable partitions and not recognizing it as an LVM partition.

One thing which might be worth looking at (although not sure if it will help epubs, although it should be able to recover PDFs) is "Photorec" - which will scan the raw disk and try and recognise content based on signatures and recover it.

Another question is are you able to add the volume back into LVM - have you played arround with the "pvscan" tool, and if so, what output have you received ?

Also have a look at this, this and this link about recovering LVM partitions. (Of-course, you really want to do a backup first - maybe DD everything to free disks if you have them)

Also, can you tell us a bit more about your setup, ie was this disk part of a single larger volume, or was each disk a separate volume, and provide the output of "pvs;vgs" - which might give some additional clues based on how other volumes were set up.

davidgo

Posted 2013-09-22T06:35:52.100

Reputation: 49 152

I did try Photorec initially, unfortunately it does not recognize epub files and I have been unable to create a working epub signature. Regarding "pvscan", I did not need to use it as the disk came back into the array after reboot - the problem was it got added back as an empty disk. pvs output is: /dev/sdb1 LCARS lvm2 a- 1.82t 1.62t /dev/sde1 LCARS lvm2 a- 1.82t 536.62g /dev/sdf1 LCARS lvm2 a- 1.82t 1.82t. vgs output is: LCARS 3 3 0 wz--n- 5.46t 3.97t – avggeek – 2013-09-22T11:31:00.813

I'm a confused now. How many logical volumes were on LCARS2, and can you see any data on any of them ? What does lvscan -b -a -v -P show, and what is the name of the missing volume ? Are you sure the volume is actually missing ? (as compared to existing but corrupted and thus not mounting ) – davidgo – 2013-09-22T18:47:35.323

LCARS2 is a single logical volume. I can see data in it that was spread out on other drives (sdb1,sde1) but data that was on sdf1 is no longer visible. Output of lvscan -b -a -v -P is '/dev/LCARS/music' [200.00 GiB] inherit '/dev/LCARS/movies' [1.10 TiB] inherit'/dev/LCARS/amanda-holding' [200.00 GiB] inherit. To clarify, a single drive /dev/sdf1 was mapped as /dev/LCARS/ebooks. The drive stopped responding in BIOS and fell out of the array. When it reappeared in BIOS, I added it back to /dev/LCARS but none of the files that were present before are visible. Hope this helps to clarify. – avggeek – 2013-09-25T13:11:49.803

Bugger, I'm stumped. One question though - When you ran photorec, did it find a whole lot of ZIP files ? From what I have read, EPUB's are zip archives, so I wonder if its possible for you to recover them as zip files, and then see if we can find some process to extract the real name from the ZIP and rename it ? – davidgo – 2013-09-25T18:23:43.947

I'm running photorec now and it is recovering a whole bunch of zip files - some of these are iTunes app files and others are actual epubs. Unfortunately, every single epub file seems to be corrupted, I keep getting an integrity error on one file extension within the zip container. – avggeek – 2013-09-28T02:22:53.167

Ok, this is interesting, but also something I have no knowledge of. Couple of things - any chance you could make one of these [epub] zips available for me to look at, does it always fail on the same file extension, and what happens if you simply rename the .zip to .epub ? – davidgo – 2013-09-28T03:18:56.977

I have to correct myself - in .zip format, extraction fails on multiple extensions, suggesting the complete file is corrupt :(. After renaming the .zip to .epub, any attempt to open the file in Calibre triggers an error "could not find opf" (which is what lead me to suspect perhaps it was one extension that was failing). Here is a link to an example recovered file.

– avggeek – 2013-09-29T03:14:13.690

Yup. That sucks. It looks like the zip file is corrupt. I can actually get a lot (most?) of the contents, but its still not a valid epub because some of the key data is missing. Taking a different approach, is http://askubuntu.com/questions/219151/is-it-possible-to-recover-a-partial-lvm-logical-volume of any help - ie will it allow you to DD a partial image ? (I wonder if the problem is that the blocks are scattered all over the place frustrating Photorecs ability to stitch it all back together - not that this makes much sense to me ?)

– davidgo – 2013-09-29T03:50:47.857

I don't think it will work, because the ddrescue command assumes that a LV is present on the drive. In my case, the drive does not have any LV mapped to it, I've left it unused in order to try and preserve the data on the drive. Should I be trying to DD the entire drive? – avggeek – 2013-09-29T04:58:33.880

DDing the entire drive is generally a good idea, but possibly pointless. The ideal (which is probably impractical) is to DD ALL the drives, then try to data recovery on the copies - so if it fails you can try again. I linked that link because it looked like it tried to get to a partial partition [ which is what it would DD off ]. My gut tells me that the focus should be trying to put the device back in the LVM list and force it to work somehow - but as I've not seen what you are talking about before, and as you appear to be in a different country its very difficult to grasp the missing bits. – davidgo – 2013-09-29T06:06:19.797

I do apologize if I'm not very clear in my description of the issue. I'll try and answer some of the points in your last comment. As you point out, the DD command in the link you provided attempts to get a partial partition. However it references the partition using a logical volume taken from pvdisplay -m, but in my case I cannot see a logical volume name for this drive. Regarding putting the drive back in the LVM Volume Group, the drive is already back in the LVM Volume Group. I'm starting to get the feeling that this a lost cause and I'm better off rebuilding the collection as best I can. – avggeek – 2013-09-29T06:32:19.970