Recovering data from Linux LVM with same volume group name
Although it is not a usual task for replacing/upgrading notebook internal hdd, nevertheless, I have performed one lately due to a failing hdd. smartctl reported hdd read failure and I have decided to make an early replacement. However, I still need to duplicate the hdd for recent data that has not been backup.
Cloning the hdd seems not a good option as it takes longer time and might fail to completely replicate the data due to hdd read failure. So I reinstalled OpenSUSE on the new hdd and restore relevant data on partition.
Default lvm volume group naming convention from OpenSUSE installer is somehow same as previous volume group. This will create problem when accessing data on failing hdd as I need to mount partition on lvm volume group which is same as running system. You should change the volume group name to something else other than “system” during the installation. Guess I didn’t paid too much attention during the installation and now I have 2 “system” volume groups. How should I mount the volume on failing hdd then?
Actually it is just an easy task of renaming volume group name.
1) Discover the UUID of the volume with dd by dumping the disk header.
dd if=/dev/sdb2 bs=512 count=255 skip=1 of=/tmp/sdb2.txt
Checking the output for disk UUID.
cat /tmp/sdb2.txt
You will find some thing like this.
system {
id = "8SX5aX-gQZJ-auYA-UX54-BkBA-nc4V-rNoV6v"
seqno = 6
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "dAe8PS-ThIN-Piez-pmqE-8hUv-vdGM-dyvtSO"
device = "/dev/sda2"
status = ["ALLOCATABLE"]
flags = []
dev_size = 487845855
pe_start = 384
pe_count = 59551
}
}
logical_volumes {
home {
id = "hQH10J-MouP-sNok-VNJN-53As-BYsw-b5cqS3"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 50847
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
root {
id = "nde2YD-6rgk-Ufm7-bLf7-ERTc-bHdO-kg7fwF"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 7680
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 51359
]
}
}
swap {
id = "KXGiD4-qFSH-smun-P4wS-TH14-xxfY-lWYlq8"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 2
segment1 {
start_extent = 0
extent_count = 512
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 59039
]
}
segment2 {
start_extent = 512
extent_count = 512
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 50847
]
}
}
}
}
The UUID of the volume group “system” is “8SX5aX-gQZJ-auYA-UX54-BkBA-nc4V-rNoV6v”
2) Renaming the volume group
vgrename 8SX5aX-gQZJ-auYA-UX54-BkBA-nc4V-rNoV6v oldsystem
3) Activate the renamed volume group
# vgchange oldsystem -a y
Now you should have your vg ready. Verify it with
# pvscan
Output
PV /dev/sdb2 VG oldsystem lvm2 [232.62 GiB / 0 free] PV /dev/sda2 VG system lvm2 [297.93 GiB / 23.93 GiB free] Total: 2 [530.55 GiB] / in use: 2 [530.55 GiB] / in no VG: 0 [0 ]
Check the volume
# lvscan
ACTIVE '/dev/oldsystem/home' [198.62 GiB] inherit ACTIVE '/dev/oldsystem/root' [30.00 GiB] inherit ACTIVE '/dev/oldsystem/swap' [4.00 GiB] inherit ACTIVE '/dev/system/home' [250.00 GiB] inherit ACTIVE '/dev/system/root' [20.00 GiB] inherit ACTIVE '/dev/system/swap' [4.00 GiB] inherit
That’s it. You can now mount and dump/restore the failing hdd.
Saturday, January 14th, 2012
