One of hard disks of the logical volume failed
Hi.
One of two hard disks that a logical volume was on failed. Code:
home { |
I'm not sure you are going to get much help. You can try things like testdisk/photorec, but I don't think you will get much data back. That doesn't mean none, just not much, and not necessarily all of a file.
The problem is that with a linear concatenation, you lose the entire filesystem when either one fails. The cause of such loss is due to the filesystem allocating both meta-data and data blocks scattered for opimum access. So such allocations do not/will not put all the data on one physical volume. Had pv1 and pv2 been raid volumes (other than raid0...), the raid recovery would have preserved the data. |
Be prepared to cry a lot.
It's really hard to give exact instructions without knowing the content of the "physical_volumes { ... }" section of that LVM backup file, but I would start with a new disk drive (750 GB or larger), make a 550 GB partition there, use dd to copy segment1 to the new drive, zero out the rest of the partition (probably already zeros if it's a new drive). and then see what fsck can do to reconstruct that filesystem. To do that copying of segment 1 you need to run: Code:
dd if={device for pv0} of={your new partition} bs=1M count=$((69199*4)) skip=$((7050*4 + 1})) Code:
dd if=/dev/zero of={your new partition} bs=4194304 seek=69199 If the pv1 drive is not totally dead, you can try to use ddrescue to recover as much data as possible rather than filling the rest of the partition with zeros. If that's the case, let me know and I can give more exact instructions. |
Quote:
|
Thanks a lot, rknichols. pv1 is totally dead, not even detected. Here's the "physical_volumes { ... }" you requested.
Code:
physical_volumes { |
Important is also to know what files have been lost or have corrupt contents. Will fsck show it?
|
So, it looks like pv0 was on /dev/sda5 (~297851 GiB). That might not be /dev/sda in your rescue environment, so you'll want to use blkid to identify the partition unless it's obvious which disk is which. Also, I've changed the dd parameters for copying segment 1. They were wrong before since the pe_start offset is in units of 512-byte sectors, not 4 MiB extents. I'm pretty sure it's right, now. You can try this:
Code:
dd if=/dev/sda5 bs=1M count=2 skip=$((7050*4 + 1})) | file -s - There will be no indication from fsck about what files are lost since the directories they were in are probably gone too. Also, fsck just makes the filesystem metadata consistent. It has no way to check the content of files. I suppose one way to tell what files (the ones that still exist) have blocks in the missing area would be to create a dmsetup mapping with that whole region mapped to the error target. That might be something to try even without attempting fsck, but get that copying done first so that there is something to work with without risking the original data. |
Disk is /dev/sda, since it's the only one left now.
Code:
$ sudo dd if=/dev/sda5 bs=1M count=2 skip=$((7050*4 + 1)) | file -s - |
Excellent!! Proceed with the copying.
|
I'll do the copy as soon as I get a new hard disk. In the meantime could you, please, tell how to do this?
Quote:
|
Quote:
Code:
dd if={device for pv0} of={your new partition} bs=1M count=$((69199*4)) skip=$((7050*4 + 1})) |
This is clear, I mean how to do dmsetup mapping to identify which files are in the "lost" area?
|
Sorry, totally misunderstood. I did some experimenting and found that the error mapping might not be very useful. Due to the I/O errors, the filesystem can't be mounted. You can get in and poke around with debugfs, but getting any info that way would be beyond tedious. I'll think about this for a while and see if I can come up with anything useful.
First, create a file /tmp/mymap with the following content: Code:
0 566878208 linear /dev/sdb1 0 Now, run Code:
dmsetup create badhome /tmp/mymap |
I have great news. Today I connected the disk to another PC and it worked, then connected back to original - works as well. I recreated the logical volume setup to original state and tried mounting /home. I got an error:
Code:
[ 2404.541803] EXT4-fs (dm-4): bad geometry: block count 131908608 exceeds size of device (70859776 blocks) Code:
root@lieta:/etc/lvm/archive# lvdisplay --units b EDIT: After reboot everything is fine. |
I had high hopes that testdisk file recovery would help find what files were corrupted, but when asked to recover all files it recovers a mish-mash of intact files, deleted files, and partially recovered files. You can identify the partially recovered files by the size difference. So, what I suggest is:
Code:
cd {your recovery directory} As I said before, there will be no way to tell what files were totally lost. Their names exist only in the missing part of the filesystem. That's the best I can come up with. I've already spent too much time on this, but it's been quite educational for me. |
All times are GMT -5. The time now is 11:30 PM. |