16

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:

  1. connecting the external backup HD into a USB port

  2. 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.

user9517
  • 114,104
  • 20
  • 206
  • 289
laramichaels
  • 263
  • 1
  • 2
  • 6
  • Opinion time: If you have disks to spare, you really should be looking at putting them in a RAID configuration (if even software RAID to save some coin) instead of shoehorning a solution such as this one. RAID1 or even RAID5 are both good options. – Garrett Jun 17 '14 at 03:24

4 Answers4

28

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/

vgimportclone -n orignalvgname_clone   /dev/sdx [/dev/sdy....]

sdx,sdy.. are the cloned disks which make up the vg.

vgchange -ay orignalvgname_clone

After this you should able to mount the lvs off the cloned disk.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
trekkerboy
  • 381
  • 3
  • 3
  • 4
    This should be the accepted answer. Worked for me, thanks! – neuviemeporte Jan 21 '16 at 14:25
  • This works and vgimportclone does what its name suggest. In my case I had do specify all disks and partitions that build the `vg` - for example `vgimportclone -n orignalvgname_clone /dev/sdx /dev/sdx2 /dev/sdx5` but obviously this may be very different from case to case. – Jey DWork Feb 16 '18 at 00:08
3

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 with dmsetup 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 in lvm.conf. For example, if you cloned /dev/sdx into /dev/sdy, you have to temporarily add /dev/sdx into the filter within the devices { ... } 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:

vgchange -a n originalvgname

This will deactivate the volume group called originalvgname, but because only the duplicate devices are visible, it will deactivate it on them (the original originalvgname 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.

pvchange -u physicaldevice
vgchange -u originalvgname

This will give new UUIDs to the duplicates.

vgrename originalvgname newvgname

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

Community
  • 1
Josip Rodin
  • 1,575
  • 11
  • 17
  • 'Original copy' is _backup copy_ or _backup source_ (which is live)? Then you suggest to deactivate live system and change it's UUID, correct? – catpnosis Aug 17 '15 at 09:25
  • 1
    @catpnosis The backup source, but only its *management*. Everything stays online, but LVM tools temporarily stop being able to see the original. The LVM tools then detect the duplicates, and are able to repurpose them i.e. change their UUIDs. And once you're done, you allow them to see everything, which will then work because the UUIDs no longer clash. – Josip Rodin Aug 18 '15 at 14:41
  • Thanks. This is interesting approach. Hard to understand though. _"This will deactivate the volume group on the duplicate devices"_ - but not really? – catpnosis Aug 18 '15 at 19:28
  • 1
    @catpnosis it gets activated by the preceding `vgscan` automatically, it just means that at that point in time the LVM tools see the duplicates (and not the original). The whole point is that you must not have them active both at the same time - either one or the other, not both. As soon as you get in the state where you see only the duplicates, then you can operate on them. – Josip Rodin Aug 19 '15 at 13:08
0

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).

Taisuke Yamada
  • 291
  • 2
  • 2
-1

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).

mgorven
  • 30,036
  • 7
  • 76
  • 121