Я клонировал (используя dd) жесткий диск в работающей системе на несколько резервных жестких дисков. Корневой раздел в работающей системе - это том LVM. Резервные копии предназначены для замены оригинала, а это означает, что они должны иметь тот же UUID, что и мастер.
Быстрый вопрос: возможно ли установить один из резервных HD-дисков в действующей системе? Когда я пытаюсь это сделать, LVM по понятным причинам запутывается из-за тех же UUID и имен групп томов. Следуя подсказке из [этого ответа] [1], чтобы сначала переименовать исходную группу LVM, я попытался:
подключение внешнего резервного HD в порт USB
выполняется (обратите внимание, что строка 'test' - это имя группы в этой системе)
# 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
На этом этапе я ожидал, что смогу получить доступ к отдельным логическим томам в разделе /dev/test/. Бег lvdisplayпроизводит.
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
Тем /dev/test/не менее, не существует вообще, и поэтому я не могу получить доступ к логическим томам на /dev/test/rootи, /dev/test/swap_1как предложил lvdisplay.
Ответы:
Весь смысл UUID в том, чтобы однозначно идентифицировать что-то, а то, что вы пытаетесь сделать, делает их неуникальными. Я очень сомневаюсь, что это возможно. Я поигрался с тем,
pvchange -uчтобы изменить UUID дублированного PV, но операция всегда терпела неудачу.Если вам действительно необходимо смонтировать резервные копии на работающем хосте, я предлагаю вам выполнить резервное копирование LV по отдельности (т. Е. Создать новый PV, VG и LV на устройстве резервного копирования и создать dd для каждого LV отдельно).
источник
Если вы хотите смонтировать lv с диска-клона, я нашел этот полезный метод здесь http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive- устройство-открыто слева-4175470893 /
SDX, SDY ... клонированные диски, которые составляют VG.
После этого вы сможете смонтировать lvs с клонированного диска.
источник
vg- например,vgimportclone -n orignalvgname_clone /dev/sdx /dev/sdx2 /dev/sdx5но очевидно, что это может сильно отличаться от случая к случаю.Ответ от trekkerboy / modonnell @ linuxquestions является наиболее простым, используйте
vgimportclone.Также обратите внимание, что после создания клона его необходимо активировать с помощью
vgchange -a y newvgname, а с помощью oldvgname необходимо очистить узлы устройствdmsetup remove /dev/oldvgname/*.Для справки, ниже следует более ручной метод, который, очевидно, напоминает подмножество того, что можно прочитать в источнике
vgimportclone.Вы можете сделать это, если сможете сначала временно деактивировать управление оригинальной копией, добавив в
devicesфильтр шаблон, соответствующий оригиналуlvm.conf. Например, если вы клонировали/dev/sdxв/dev/sdy, вы должны временно добавить/dev/sdxвfilterвdevices { ... }разделе.Оригинальные устройства будут оставаться в сети, но инструменты LVM будут игнорировать их. Установленные на них файловые системы останутся подключенными и работоспособными, что не тесно связано с управлением LVM.
После установки фильтра выполните новое
vgscan, чтобы убедиться, что дубликаты и только они теперь находятся под управлением LVM. Вы можете убедиться, что вы видите дубликаты/dev/sdyустройств, например, черезpvs.Затем сделайте:
Это деактивирует вызываемую группу томов
originalvgname, но поскольку видны только дубликаты устройств, она деактивирует их на них (оригиналoriginalvgnameуже невидим из-за фильтра выше). Этот шаг необходим для того, чтобы вы могли свободно изменять атрибуты неактивной группы томов и входящих в нее физических томов.Это даст новые идентификаторы UUID дубликатам.
Это переименует дублированную группу томов.
После этого вы можете удалить фильтр
lvm.confи выполнить повторное сканирование, и оба набора устройств LVM будут видны под разными именами и UUID.В качестве альтернативы, если вы на самом деле не заинтересованы в сохранении исходного имени VG и идентификаторов UUID PV / VG, вы можете вместо них избавиться от них, cf. /superuser/256061/lvm-and-cloning-hds
источник
vgscanавтоматически, это просто означает, что в этот момент инструменты LVM видят дубликаты (а не оригинал). Все дело в том, что вы не должны активировать их одновременно - ни то, ни другое, а не оба. Как только вы попадете в состояние, в котором вы видите только дубликаты, вы сможете оперировать ими.Я столкнулся с этой проблемой только вчера. У меня есть файловая система (LVM (MD (sda, sdb, sdc-syncing-only-weekly-based))) в Linux, и мне нужен был доступ к старым данным на sdc.
Я несколько решил проблему, подключив резервный диск (sdc) к виртуальной машине. Это безопасная операция, пока я подключаю диск с помощью «qemu ... -drive file = / dev / sdc, readonly» (или использую опцию снимка для конфигурации копирования при записи).
источник