On Fri, Feb 27, 2015 at 5:35 PM, Khemara Lyn <lin.kh(a)wicam.com.kh> wrote:
Dear All,
I am in desperate need for LVM data rescue for my server.
I have an VG call vg_hosting consisting of 4 PVs each contained in a
separate hard drive (/dev/sda1, /dev/sdb1, /dev/sdc1, and /dev/sdd1).
And this LV: lv_home was created to use all the space of the 4 PVs.
Mirrored? Or linear (default)? If this is linear, then it's like one
big hard drive. The single drive equivalent of losing 1 of 4 drives in
linear would be ablating 1/4 of the surface of the drive making it
neither readable nor writable. Because critical filesystem metadata is
distributed across the whole volume, the filesystem is almost
certainly irreparably damaged.[1]
Right now, the third hard drive is damaged; and therefore the third
PV
(/dev/sdc1) cannot be accessed anymore.
Damaged how? Is it dead?
What file system?
I would like to recover whatever
left in the other 3 PVs (/dev/sda1, /dev/sdb1, and /dev/sdd1).
I have tried with the following:
1. Removing the broken PV:
# vgreduce --force vg_hosting /dev/sdc1
Physical volume "/dev/sdc1" still in use
# pvmove /dev/sdc1
No extents available for allocation
2. Replacing the broken PV:
I was able to create a new PV and restore the VG Config/meta data:
# pvcreate --restorefile ... --uuid ... /dev/sdc1
# vgcfgrestore --file ... vg_hosting
However, vgchange would give this error:
# vgchange -a y
device-mapper: resume ioctl on failed: Invalid argument
Unable to resume vg_hosting-lv_home (253:4)
0 logical volume(s) in volume group "vg_hosting" now active
Could someone help me please???
# vgcfgrestore -tv vg_hosting
If this produces some viable sign of success then do it again without
the -t. If you get scary messages, I advise not proceeding. If the
command without -t succeeds then try this:
# lvs -a -o +devices
In any case, there's a huge hole where both filesystem metadata and
file data was located, so I'd be shocked (like, really shocked) if
either ext4 or XFS will mount, even read only. So I expect this is
going to be a scraping operation with testdisk or debugfs.
[1] Btrfs can survive this to some degree because by default the
filesystem (metadata) is dup on single drive (except SSD) and raid1 on
multiple devices. So while you lose files (data) on the missing drive,
the fs itself is intact and will even mount normally.
--
Chris Murphy