I have cloned (using dd) the hard drive in a live system onto several multiple backup hard drives. The root partition in the live system is a LVM volume. The backup copies are intended to be drop-in replacements for the original and this means they need to have the same UUID as the master.
Quick question: is it possible to mount one of the backup HDs on the live system? When I try to do so LVM is understandably confused about this due to the same UUIDs and volume group names. Following the hint found in [this answer][1] to first rename the original LVM group, I have tried:
connecting the external backup HD into a USB port
running (note that the string 'test' is the group name on this system)
# vgrename test test-live Volume group "test" successfully renamed to "test-live" vgscan --mknodes Reading all physical volumes. This may take a while... Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0 Found volume group "test" using metadata type lvm2 # vgchange -ay Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0 2 logical volume(s) in volume group "test" now active
At this point I would have expected to have been able to access the individual logical volumes under /dev/test/
. Running lvdisplay
produces.
Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0
--- Logical volume ---
LV Name /dev/test/root
VG Name test
LV UUID UuKUH3-yzPo-CbOz-tU4B-W6om-qdMn-0XSNZU
LV Write Access read/write
LV Status available
# open 1
LV Size 126.48 GiB
Current LE 32378
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:1
--- Logical volume ---
LV Name /dev/test/swap_1
VG Name test
LV UUID OGJhJu-QByo-6AzG-sk1x-jh3e-dU9L-sHk91t
LV Write Access read/write
LV Status available
# open 2
LV Size 3.90 GiB
Current LE 999
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:2
However, /dev/test/
does not exist at all and therefore I cannot access the logical volumes at /dev/test/root
and /dev/test/swap_1
as lvdisplay suggested.
If you want to mount the lv's from a clone disk, I found this useful method here http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive-device-left-open-4175470893/
sdx,sdy.. are the cloned disks which make up the vg.
After this you should able to mount the lvs off the cloned disk.
The answer by trekkerboy / modonnell @ linuxquestions is most straightforward, use
vgimportclone
.Note also that after you create the clone, you have to activate it with
vgchange -a y newvgname
, and you have to clean up oldvgname's device nodes withdmsetup remove /dev/oldvgname/*
.For reference, what follows is a more manual method, which apparently resembles a subset of what one can read in the source of
vgimportclone
.You can do it if you're able to first temporarily deactivate management of the original copy, by adding a pattern matching the original into the
devices
filter inlvm.conf
. For example, if you cloned/dev/sdx
into/dev/sdy
, you have to temporarily add/dev/sdx
into thefilter
within thedevices { ... }
section.The original devices will stay online, but LVM tools will ignore them. Mounted filesystems on them will remain mounted and operational, that's not tightly coupled with LVM management.
After the filter is in place, do a new
vgscan
, to make sure the duplicates and only them are now under LVM management. You can make sure you see the duplicate/dev/sdy
devices via e.g.pvs
.Then do:
This will deactivate the volume group called
originalvgname
, but because only the duplicate devices are visible, it will deactivate it on them (the originaloriginalvgname
is already invisible because of the filter above). This step is necessary so that you can then freely change attributes of the now-inactive volume group and its constituent physical volumes.This will give new UUIDs to the duplicates.
This will rename the duplicated volume group.
After that, you can remove the filter from
lvm.conf
and rescan again, and both sets of LVM devices will be visible, under different names and UUIDs.Alternatively, if you're not actually interested in keeping the original VG name and PV/VG UUIDs, you can dispose of them, instead, cf. https://superuser.com/questions/256061/lvm-and-cloning-hds
I encountered this problem just yesterday. I have filesystem(LVM(MD(sda, sdb, sdc-syncing-only-weekly-basis))) configuration on Linux, and needed to access old data on sdc.
I somewhat solved the issue by attaching backup disk (sdc) to a VM. This is a safe operation as long as I attach the disk with "qemu ... -drive file=/dev/sdc,readonly" (or use a snapshot option for copy-on-write configuration).
The whole point of UUIDs is to uniquely identify something, and what you're trying to do makes them non-unique. I highly doubt that this is possible. I played around with
pvchange -u
to change the UUID of a duplicated PV, but the operation always failed.If you really need to mount the backups on the live host, I suggest that you backup the LVs individually (i.e. create a new PV, VG and LVs on the backup device and dd each LV separately).